Модели процессов

---

5.1. Состав функциональной модели

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги (стрелки). Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (оборудование, персонал или автоматизированная система), который осуществляет операцию, представляется стрелкой, входящей в блок снизу (рисунок 5.1).

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

Рис.5.1 – Функциональный блок и четыре типа интерфейсных дуг (стрелок)

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

5.2. Иерархия диаграмм

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

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

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

Рис. 5.2 – Структура SADT-модели. Декомпозиция диаграмм

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

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

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

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

Рис. 5.3 – Одновременное выполнение функций

Рис. 5.4 – Соответствие дуг и функций должно быть полным

и непротиворечивым

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

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

Например, на рисунке 5.5, отображающем процесс разработки конструкторской документации (КД), дуга «Архивные файлы других отделов» отражает обратную связь по управлению, «Неутвержденная КД» – обратную связь по выходу/входу. Выход «Утвержденная КД» становится управлением для функции «Создание архива». Выход работы «Разработка ТЗ» является входом работы «Разработка КД и файлов по ТЗ». Функции «Утверждение ТЗ» и «Документооборот» могут выполняться одновременно.

Рис. 5.5 – Пример обратной связи по управлению

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

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

Рис. 5.6 – Пример входов (слева), выходов (справа), управлений (сверху)

и механизмов (снизу) на контекстной диаграмме

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 5.7 показано типичное дерево диаграмм (Node Tree).

Рис. 5.7 – Иерархия диаграмм в виде дерева (Node Tree)

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

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

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

5.3. Типы связей между функциями

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

Диаграмму SADT уровня ниже контекстной теоретически можно было бы нарисовать на одном листе огромного размера, разместив на нем все функции, число которых может достигать сотен-тысяч и более. Поскольку это не удобно, рисуют иерархию диаграмм декомпозиции, каждая из которых содержит до 10 блоков (рекомендуется 4-6 блоков на одной диаграмме). Разделить общую гипотетическую диаграмму на диаграммы декомпозиции можно разными путями.

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

Различают, по крайней мере, семь типов связывания (табл. 5.1).

Таблица 5.1 – Типы связывания функциональных блоков

Тип связи	Относительная значимость
Случайная	0
Логическая	1
Временная	2
Процедурная	3
Коммуникационная	4
Последовательная	5
Функциональная	6

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

(0) Тип случайной связности: наименее желательный.

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

Рис. 5.8 – Случайная связность

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

(2) Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно. Рисунок аналогичен рис. 5.8.

(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке 5.9.

Рис.5.9 – Процедурная связность

(4) Тип коммуникационной связности. Диаграммы демонстрируют коммуникационные связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рисунок 5.10).

Рис. 5.10 – Коммуникационная связность

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

Рис. 5.11 – Последовательная связность

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

Рис. 5.12 – Функциональная связность

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

C = g(B) = g(f(A))

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

Таблица 5.2 – Значимость типов связности

Значи-мость	Тип связности	Для функций	Для данных
0	Случайная	Случайная	Случайная
1	Логическая	Функции одного и того же множества или типа (например, "редактировать все входы")	Данные одного и того же множества или типа
2	Временная	Функции одного и того же периода времени (например, "операции инициализации")	Данные, используемые в каком-либо временном интервале
3	Процедурная	Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора")	Данные, используемые во время одной и той же фазы или итерации
4	Коммуника­ционнная	Функции, использующие одни и те же данные	Данные, на которые воздействует одна и та же деятельность
5	Последова­тельная	Функции, выполняющие последовательные преобразования одних и тех же данных	Данные, преобразуемые последовательными функциями
6	Функцио­нальная	Функции, объединяемые для выполнения одной функции	Данные, связанные с одной функцией

5.4. Моделирование процессов по стандарту IDEF0

Процесс моделирования какой-либо системы в IDEF0 начинается с оп­ределения контекста, т.е. наиболее абстрактного уровня описания системы в целом.

В контекст входит определение:

- субъекта моделирования (Области моделирования – Scope);

- цели моделирования (Purpose);

- точки зрения на модель (Viewpoint).

Область моделирования (Scope). Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматри­вать как компоненты системы, а что как внешнее воздействие. На опреде­ление субъекта системы будет существенно влиять позиция, с которой рас­сматривается система, и цель моделирования – вопросы, на которые по­строенная модель должна дать ответ. Другими словами, первоначально не­обходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначаль­но, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необ­ходимо учитывать два компонента – широту и глубину. Широта подразуме­вает определение границ модели – мы определяем, что будет рассматри­ваться внутри системы, а что снаружи. Глубина определяет, на каком уров­не детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени – трудоемкость построения модели растет в геометрической профессии от глубины деком­позиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объ­екты модели взаимосвязаны, внесение нового объекта может быть не про­сто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плава­ющей области").

Цель моделирования (Purpose). Модель не может быть построена без чет­ко сформулированной цели. Цель должна отвечать на следующие вопросы:

- Почему этот процесс должен быть промоделирован?

- Что должна показывать модель?

- Что может получить пользователь модели?

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

Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит сис­тему в нужном для моделирования аспекте. Точка зрения должна соответ­ствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответствен­ного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only).

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесе­ния области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения, а в за­кладку Definition – определение модели и описание области.

В закладке Status того же диалога можно описать статус модели (черно­вой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построе­ния модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели – AS-IS и ТО-ВЕ.

5.5. Модели AS-IS и ТО-ВЕ

Обычно сначала строится модель существую­щей организации работы – AS-IS (как есть). На основе модели AS-IS дос­тигается консенсус между различными единицами бизнеса по тому, "кто что сделал" и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыг­нуть на то, "что мы будем делать завтра". Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состо­ять преимущества новых бизнес-процессов и насколько глубоким измене­ниям подвергнется существующая структура организации бизнеса. Детали­зация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Призна­ками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный до­кумент не оказывается в нужном месте в нужное время), отсутствие обрат­ных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при созда­нии модели ТО-ВЕ (как будет) – модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших пу­тей выполнения работы и документирования того, как компания будет де­лать бизнес в будущем.

Следует указать на распространенную ошибку при создании модели AS-IS – это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного испол­нителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную ин­формацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD-BE (как должно бы быть, хорошо бы так было).

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу "все оставить как есть, только чтобы компьютеры стояли", т. е. ИС автоматизирует несо­вершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.

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

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

Model Name: Movie Rental

Definition: Учебная модель

Scope: Технологические, Финансовые и управленческие аспекты деятельности условного предприятия.

Viewpoint: Руководитель предприятия

Purpose: Описать функциональность предприятия с целью написания спецификаций информационной системы.

Рис. 5.13 – Отчет по модели

5.6. Моделирование в стандарте IDEF0

Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диа­грамм. Каждая диаграмма является единицей описания системы и распо­лагается на отдельном листе [9].

Модель может содержать четыре типа диаграмм:

- контекстную диаграмму (в каждой модели может быть только одна кон­текстная диаграмма);

- диаграммы декомпозиции;

- диаграммы дерева узлов;

- диаграммы только для экспозиции (FEO).

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

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

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

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

Построение диаграмм рассмотрим на примере разработки модели процессов информационной системы для хранения и учета конструкторской документации

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

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

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

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

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

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

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

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

Например, при "Обработке анкеты" анкета может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назна­чение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе – "Проверенная анкета "). Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 5.14 стрелки "Стандарты, нормативные документы, справочники", "Данные о сотрудниках", "Данные о разработках" являются управ­лением для работы "Хранение и учет конструкторской документации". Управление влияет на работу, но не преобразуется работой. Если цель работы – изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

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

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

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

Например, если работа заключается во вводе в ЭВМ данных с бумажного бланка анкет (даже без изменения их смыслового содержания), тогда:

- входом будут смысловые данные (информация), записанные в бумажном бланке анкеты;

- выходом будут данные в электронной форме;

- управлением будут: состав вопросов анкеты, правила заполнения анкеты и проверки данных на допустимые значения, формат бланка анкеты и т.п.

Выход (Output) – материал или информация, которые производятся ра­ботой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка вы­хода рисуется как исходящая из правой грани работы. На рис. 5.14 стрелка "Архивная КД " является выходом для работы "Хранение и учет конструкторской документации".

Механизм (Mechanism) – ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рису­ется как входящая в нижнюю грань работы. На рис. 5.14 стрелка "Персонал предприятия" является механизмом для работы "Хранение и учет конструкторской документации". По усмотрению аналитика стрелки механизма могут не изображаться в модели (или туннелироваться).

Вызов (Call) – специальная стрелка, указывающая на другую модель ра­боты. Стрелка вызова рисуется как исходящая из нижней грани работы. Стрелка "Другая модель хранения документации" является вызовом для работы "Хранение и учет конструкторской документации". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.

В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

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

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

Рис. 5.15 – Пример несвязанных стрелок

На рис. 5.15 приведен фрагмент диаграммы декомпозиции с несвязан­ными стрелками, генерирующийся BPwin при декомпозиции работы "Хранение и учет конструкторской документации" (см. рис. 5.14). Стрелки входа, выхода, управления и механизма необходимо связать с соответствующими им блоками.

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

В IDEF0 различают пять типов связей работ.

1) Связь по входу (output-input), когда стрелка выхода вышестоящей рабо­ты (далее – просто выход) направляется на вход нижестоящей (например, на рис. 5.17 стрелка "Файлы документов" связывает работы "разработка ТЗ" и "Разработка КД и файлов ТЗ").

2) Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показыва­ет доминирование вышестоящей работы. Данные или объекты выхода вы­шестоящей работы не меняются в нижестоящей. На рис. 5.17 стрелка "Утвержденная КД" связывает работы "Утвержденная КД" и "Создание архива"), при этом чертеж не претерпевает изменений в процессе изготов­ления деталей.

3) Обратная связь по входу (output-input feedback), когда выход нижестоя­щей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. 5.17 стрелка "Неутвержденная КД " связывает работы "Утверждение КД" и "Разработка КД и файлов ТЗ", при этом выявлен­ные при утверждении несоответствия КД направляются для устранения замечаний.

4) Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Рекомендации", рис. 5.17). Обратная связь по управлению часто свидетельствует об эффективности бизнес – процесса. На рис. 5.17 стрелка "Архивные файлы других отделов" связывает работы "Документооборот" и "Разработка КД и файлов ТЗ", при этом возможно повторное использование архивных файлов или их фрагментов при разработке КД. На рис. 5.17 качество документации может быть повышено путем непосредственного регулирования процессами разработки в зависимости от результатов (выхода) работы "Документооборот" (наличия аналогичной документации в архиве).

5) Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже ос­тальных и показывает, что одна работа подготавливает ресурсы, необходи­мые для проведения другой работы (рис. 5.16).

Несвязанные граничные стрелки (unconnected border arrow). При деком­позиции работы входящие в нее и исходящие из нее стрелки (кроме стрел­ки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки назы­ваются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

Рисунок 5.16 – Связь выход-механизм

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

Рисунок 5.17 – Диаграмма декомпозиции первого уровня

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

Смысл разветвляющихся и сливающихся стрелок передается именова­нием каждой ветви стрелок. Существуют определенные правила именова­ния таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис. 5.18).

Рисунок 5.18 – Именование разветвляющихся стрелок

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.

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

Первый блок первого подуровня модели процессов называется «Разработка ТЗ» и содержит подуровень, который более детально раскрывает этот блок (рисунок 5.19).

Рисунок 5.19 –Второй подуровень «Разработка ТЗ»

Первый блок «Разработка ТЗ и прикрепление файлов» декомпозирован на третий подуровень (рисунок 5.20).

Рисунок 5.20 –Третий подуровень «Разработка ТЗ и прикрепление файлов»

Блок «Разработка ТЗ и прикрепление файлов» подразумевает создание документа технического задания (блок «Создание файла документа ТЗ»), создание новой записи о задании в БД – номер ТЗ, название, тема (блок «Создание нового ТЗ в БД») и прикрепление к заданию файлов, необходимых для его выполнения (блок «Прикрепление к ТЗ файлов необходимых для разработки»).

Блок «Визирование и простановка сроков» (рисунок 5.19) имеет смысл в том, что новое задание должно быть завизировано начальником подразделения разработчика ТЗ (задание может составлять как сотрудник, так и начальник). Начальник должен назначить подразделение-исполнитель и назначить сроки разработки по ТЗ.

Блок «Отправка в отдел-исполнитель» подразумевает, что после визирования ТЗ, у начальника отдела исполнителя появляется запись о новых невыполненных заданиях. После этого он должен назначить конкретного исполнителя, что и показано на четвертом блоке «Назначение исполнителя».

Второй блок «Разработка КД и файлов по ТЗ» (рисунок 5.17) отображает процесс полной разработки документации, файлов для производства и сопутствующих файлов, печати конструкторской документации, обмена информацией с другими подразделениями, что подразумевается в блоке «Документооборот».

Третий блок «Утверждение КД» (рисунок 5.17) отображает, что разработанная документация должна быть проверена начальником, нормоконтролером и утверждена во всех инстанциях. Если КД не утверждена, ее нужно доработать и исправить ошибки. После утверждения КД разработчик имеет право делать электронный архив файлов.

Четвертый блок «Создание архива» отображает порядок создания архива и детализирован на втором подуровне на три составляющих функции (рисунок 5.21).

Рисунок 5.21 –Второй подуровень «Создание архива»

Блок «Создание папки архива» (рисунок 5.21) подразумевает создание названия архива и выбор номера ТЗ, после чего происходит создание папки хранения архива на сервере БД. Второй блок «Прикрепление файлов» показывает запись файлов в папку архива. Третий блок «Сохранение и ввод информации об архиве» выполняет сохранение данных об авторе архива, присвоение версии архива и простановку даты создания архива.

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

Шестой блок «Документооборот» второго подуровня модели процессов (рисунок 5.17) отображает работы по хранению и извлечению файлов документации из архивов.

Тоннелирование стрелок. Вновь внесенные граничные стрелки на диа­грамме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рис. 5.22)

Рис. 5.22 – Неразрешенная (unresolved) стрелка

Тоннелирование может быть применено для изображения малозначи­мых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо на­править на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутст­вует. Выходом является тоннелирование стрелки на самом нижнем уровне. Такое Тоннелирование называется "не-в-родительской-диаграмме". Например, стрелки «Брак», «Отходы» можно тоннелировать на соответствующем уровне.

Другим примером тоннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исклю­чения. (Предполагается, что не нужно детализировать стрелку механизма, т.е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеют собственного имени). В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на водительской диаграмме она может быть затоннелирована, а в комментарии к стрелке или в словаре можно указать, что механизм будет использо­ваться во всех работах дочерней диаграммы декомпозиции. Такое тоннелирование называется "не-в-дочерней-работе" (рис. 5.23). Оно означает, что все работы нижестоящего уровня могут использовать затоннелированный механизм по умолчанию.

Рис. 5.23 – Типы тоннелирования стрелок

5.7. Нумерация работ и диаграмм

Все работы модели нумеруются. Номер состоит из префикса и числа Может быть использован префикс любой длины, но обычно использую* префикс А. Контекстная (корневая) работа дерева имеет номер АО. Работы декомпозиции АО имеют номера Al, A2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядке вый номер, например работы декомпозиции A3 будут иметь номера А31 А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию – нумерацией по узлам. Имеются незначительные варианты нумерации.

Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграмм имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-1 декомпозиция контекстной диаграммы – номер А0, остальные диаграмм декомпозиции – номера по соответствующему узлу (например, А1, А2, А2, А13 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т.е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могу быть созданы различные версии одной и той же (с точки зрения ее pacnоложения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии, либо как FEO диаграмму. В любом случае следует отличать различные версии одно и той же диаграммы. Для этого существует специальный номер – C-number, который должен присваиваться автором модели вручную. C-number – произвольная строка, но рекомендуется придерживаться стандарта, который, например, состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а поряд­ковый номер отслеживается автором вручную, например SM00011.

5.8. Диаграммы дерева узлов и FEO

Диаграмма дерева узлов показывает иерархию работ в модели и позво­ляет рассмотреть всю модель целиком, но не показывает взаимосвязи меж­ду работами (стрелки) (рис. 5.24). Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ деком­позиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, BPwin имеет мощный инструмент навигации по модели – Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако этот инструмент не является состав­ляющей стандарта IDEF0.

Рис. 5.24 – Диаграмма дерева узлов

5.9. Каркас диаграммы

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

Смысл элементов каркаса приведен в табл. 5.3 и 5.5.

Таблица 5.3 – Поля заголовка каркаса (слева направо)

Поле	Смысл
Used At	Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посред­ством стрелки вызова
Autor, Date, Rev, Project	Имя создателя диаграммы, дата создания и имя проек­та, в рамках которого была создана диаграмма. REV-дата последнего редактирования диаграммы
Notes 12345678910	Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания
Status	Статус отображает стадию создания диаграммы, ото­бражая все этапы публикации
Working	Новая диаграмма, кардинально обновленная диаграм­ма или новый автор диаграммы
Draft	Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению
Recommended	Диаграмма и все ее сопровождающие документы про­шли экспертизу. Новых изменений не ожидается
Publication	Диаграмма готова к окончательной печати и публика­ции
Reader	Имя читателя (эксперта)
Date	Дата прочтения (экспертизы)
Context	Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмме (А-0) показывается надпись ТОР. В левом нижнем углу показывается номер по узлу родительской диаграммы:

Таблица 5.4 – Поля подвала каркаса (слева направо)

Поле	Смысл
Node	Номер узла диаграммы (номер родительской работы)
Title	Имя диаграммы. По умолчанию – имя родительской работы
Number	C-Number, уникальный номер версии диаграммы
Page	Номер страницы, может использоваться как номер страницы при формировании папки

5.10. Рекомендации по рисованию диаграмм

В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, раз­ветвляться и пресекаться. Такие диаграммы могут стать очень плохо читае­мыми. В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих пра­вил AllFusion Process Modeler (BPwin) поддерживает автоматически, выполнение других следует обес­печить вручную.

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

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

Обратные связи по входу рисуются "нижней" петлей, обратная связь по управлению – "верхней". BPwin автоматически ри­сует обратные связи нужным образом. Его можно "обмануть", но лучше этого не делать.

Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемого объекта. Принято изображать такие связи на диаграмме декомпозиции. BPwin не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала соз­дать обычную связь по входу, затем разветвить стрелку, направить но­вую ветвь обратно к входу работы-источника и, наконец, удалить ста­рую ветвь стрелки выхода

Следует вручную минимизировать число пересечений, петель и поворотов стре­лок.

Если нужно изобразить связь по входу, необходимо избегать "нависания" работ друг над другом. В этом случае BPwin изображает связи по входу в виде петли, что затрудняет чтение диаграмм.

Панель инструментов BPwin [9] содержит инструменты для рисова­ния объектов в диаграмме. В BPwin существует три разных панели инструментов — по числу поддерживаемых програм­мой методологий (IDEF0 DFD IDEF3) .

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

Таблица 5.5 – Основные приемы работы с BPwin

Операция	Выполняемые действия
Добавление дерева узлов	Diagram/Add NodeTree…
Добавление FEO диаграммы	Diagram/Add FEO diagram…
Задание свойств диаграммы	Diagram Properties…
Связывание стрелок входа, управления или механизма	Перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и щелкнуть по соответствую­щему сегменту работы.
Связывание стрелки выхода	Перей­ти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.
Рисование стрелки выхода	щелкнуть по кнопке с символом стрелки в палитре инструментов, щелкнуть в правой части работы со стороны выхода (где начинается стрелка), перенести кур­сор к правой стороне экрана, пока не появится начальная штриховая по­лоска, и щелкнуть один раз по штриховой полоске
Рисование внутренней стрелки	В режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой
Слияние двух стрелок вы­хода	В режиме редактирования стрелок сначала щелкнуть по сегмен­ту выхода работы, а затем по соответствующему фрагменту стрелки
Разветвление стрел­ки	В режиме редактирования стрелки щелкнуть по фрагменту стрел­ки и по соответствующему сегменту работы
Задание значения полей каркаса	Задаются в диалоге Diagram Properties (меню Edit/Diagram Properties)
Задание имени работы	Щелкнуть правой кнопкой мышки по блоку работы, в открывшемся контекстном меню выбрать name
Задание имени стрелки	Щелкнуть правой кнопкой мышки по стрелке, в открывшемся контекстном меню выбрать name
Увеличение расстояния между входящими или выходящими стрелками на одной грани работы	Включить опцию Line Drawing: Automatically space arrows на закладке Layout диалога Model Properties (меню Edit/Model Properties), BPwin будет располагать стрелки нужным образом автоматически
Настройка шрифтов по умолчанию	В начале работы с BPwin полезно настроить все шрифты по умолчанию: - в Model/Default Fonts/Context Activity… (и так для ВСЕХ 11 типов объектов). При этом активируйте флажок Change all occurrences of this font in the model
Русификация шрифтов (если они не устанавливаются для модели)	Внести изменения в реестр Windows: нужно изменить 2 значения в реестре Windows (Пуск/Выполнить/команда Regedit) в HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control / Nls / CodePage 1) для 1250 : Value data (Значение) = c_1251.nls 2) для 1252 : Value data (Значение) = c_1251.nls После этого русские буквы будут работать и в диаграммах и в словарях