Т.Е. Точилкина, И.Л. Катков,

ФГОУ ВПО «АКАДЕМИЯ БЮДЖЕТА И КАЗНАЧЕЙСТВА

МИНИСТЕРСТВА ФИНАНСОВ РОССИЙСКОЙ ФЕДЕРАЦИИ»

 

Т.Е. Точилкина, И.Л. Катков,

В.М. Лебедев, Н.А. Мещерякова

ПРИНЦИПЫ СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ С ИСПОЛЬЗОВАНИЕМ ПАКЕТА ПРОГРАММ
ALLFUSION MODELING SUITE.

Часть I

АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ
AllFusion Process Modeler

Учебно-методическое пособие

по дисциплине «Информационные системы в экономике»

Москва 2007

 

 

Т.Е. Точилкина, И.Л. Катков,

В.М. Лебедев, Н.А. Мещерякова

Принципы создания информационных систем и моделирования бизнес-процессов с использованием пакета программ AllFusion Modeling Suite. Часть I. Автоматизированная информационная система моделирования бизнес-процессов AllFusion Process Modeler. Учебно-методическое пособие. – М.: изд. Академии бюджета и казначейства, 2007. - 145 с.

 

© Академия бюджета и казначейства, 2007

 

© Т.Е. Точилкина, И.Л. Катков,
В.М. Лебедев, Н.А. Мещерякова

Содержание

1. Введение в проектирование информационных систем.................................................... 5

1.1. Состав АИС............................................................................................................................................................... 5

1.2. Этапы создания АИС........................................................................................................................................... 5

1.3. Требования к инструментам разработки АИС.......................................................................................... 6

1.4. Методика разработки АИС с помощью продуктов пакета AllFusion Modeling Suite........ 7

2. Основные характеристики AllFusion Process Modeler................................................... 14

2.1. Описание AllFusion Process Modeler...................................................................................................... 14

2.2. Функциональные возможности AllFusion PM..................................................................................... 15

3. Инструментальная среда AllFusion PM........................................................................................... 20

3.1. Интерфейс AllFusion PM 7.2........................................................................................................................... 20

3.2. Русификация AllFusion PM............................................................................................................................ 22

3.3. Навигатор модели Model Explorer........................................................................................................... 23

3.4. Стандартный бланк диаграммы.................................................................................................................. 25

4. Построение модели в AllFusion PM..................................................................................................... 30

4.1. Система и модель в AllFusion PM.............................................................................................................. 30

4.2. Этапы построения модели............................................................................................................................. 32

4.3. Начало создания модели в AllFusion PM............................................................................................... 37

4.4. Диалог Model Properties и продолжение моделирования............................................................. 39

4.5. Построение функциональных диаграмм (IDEF0)................................................................................. 46

Состав IDEF0-модели............................................................................................................................................. 46

Состав IDEF0-диаграммы..................................................................................................................................... 46

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

Этапы построения диаграмм IDEF0................................................................................................................... 56

Палитра инструментов для построения диаграмм IDEF0........................................................................... 57

4.6. Построение диаграмм потоков данных (DFD)...................................................................................... 58

Состав DFD-модели................................................................................................................................................. 58

Состав DFD-диаграммы......................................................................................................................................... 58

Нумерация объектов............................................................................................................................................... 60

Этапы построения диаграмм DFD...................................................................................................................... 60

Палитра инструментов для построения диаграмм DFD............................................................................... 63

4.7.Построение диаграмм потоков процессов (IDEF3). Сценарии....................................................... 64

Состав IDEF3-модели............................................................................................................................................. 65

Состав IDEF3-диаграммы..................................................................................................................................... 65

Сценарии и декомпозиции работ........................................................................................................................ 72

Нумерация объектов............................................................................................................................................... 73

Этапы построения диаграмм IDEF3................................................................................................................... 75

Палитра инструментов для построения диаграмм IDEF3........................................................................... 76

4.8. Дополнительные диаграммы........................................................................................................................ 77

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

FEO – диаграммы только для показа................................................................................................................. 78

Организационные диаграммы.............................................................................................................................. 79

Диаграммы Swim Lane........................................................................................................................................... 82

4.9. Построение смешенной модели, включающей диаграммы IDEF0, IDEF3, DFD..................... 83

Декомпозиция работы IDEF0 в диаграмму DFD............................................................................................. 83

Граничные стрелки на диаграммах IDEF0 и DFD.......................................................................................... 84

Декомпозиция работы IDEF0 или DFD в диаграмму IDEF3........................................................................ 85

4.10. Использование нетрадиционного синтаксиса на диаграммах модели............................... 85

5. Слияние/расщепление моделей для организации одновременной работы. 88

5.1. Расщепление моделей...................................................................................................................................... 88

5.2. Слияние моделей................................................................................................................................................ 90

6. Анализ моделей в AllFusion PM............................................................................................................... 92

6.1. Обнаружение синтаксических ошибок в диаграммах модели..................................................... 92

6.2. ABC – функционально стоимостной анализ......................................................................................... 93

6.3. UDP – свойства, определяемые пользователем.................................................................................... 97

Создание UDP........................................................................................................................................................... 99

Прикрепление UDP к объектам модели........................................................................................................... 101

Сопутствующая документация и UDP............................................................................................................. 102

Генерация отчетов по UDP................................................................................................................................. 103

Поддерживаемые типы UDP............................................................................................................................... 105

7. Создание отчетов в AllFusion PM........................................................................................................ 108

7.1. Создание текстовых отчетов на основе встроенных шаблонов.............................................. 108

7.2. Создание отчетов с помощью встроенного построителя шаблонов отчетов Report Template Builder. 111

9. Задание для самостоятельной работы........................................................................................ 121

Приложение А. Стадии и этапы создания АИС.............................................................................. 123

Приложение B. Пример модели «Моделирование бизнес-процессов» (IDEF0).. 125

Приложение C. Пример модели «Цикл IDEF-папки» (IDEF3)................................................... 131

Приложение D. Фрагмент функциональной метамодели абстрактной деятельности (IDEF0).................................................................................................................................................................................................. 135

Приложение E. Пример модели деятельности предприятия ООО «Ресурс» (IDEF0). 140

Приложение F. Типы UDP и их характеристика............................................................................ 142

Литература................................................................................................................................................................... 144

Состав АИС.

Автоматизированные информационные системы (АИС) и их компоненты являются сложными системами. В состав АИС входят следующие виды обеспечения (ГОСТ 34.602-89):

· Техническое обеспечение,

· Информационное обеспечение,

· Программное обеспечение,

· Математическое обеспечение,

· Организационное обеспечение,

· Лингвистическое обеспечение,

· Методическое обеспечение,

· Метрологическое обеспечение,

· Другие. виды обеспечения.

Этапы создания АИС.

Выделяют следующие стадии создания АИС (ГОСТ 34.601-90):

1. Формирование требований,

2. Разработка концепции,

3. Техническое задание,

4. Эскизный проект,

5. Технический проект,

6. Рабочая документация,

7. Ввод в действие,

8. Сопровождение АС.

В Приложении А приведена информация об этапах работ по созданию АИС.

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

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

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

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

Результаты анализа - техническое предложение и бизнес-план создания АИС - представляются заказчику для окончательного согласования.

Требования к инструментам разработки АИС.

Технология создания АИС предъявляет особые требования к методикам реализации и программным инструментальным средствам. К таким требованиям можно отнести следующее:

1. Реализацию проектов по созданию АИС принято разбивать на стадии и этапы, перечисленные выше. Известно, что наиболее критическими являются первые стадии проекта. Так, аналитическая компания Gartner Group, проводя оценку стоимости ошибки на различных стадиях подготовки производства, выявила следующую закономерность: ошибка в $1, допущенная на стадии концептуального проектирования, обходится в $1000000 на стадии серийного производства. Поэтому крайне важно иметь эффективные средства автоматизации ранних этапов реализации проекта.

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

3. Жизненный цикл создания сложной АИС сопоставим с ожидаемым временем ее эксплуатации. Другими словами, в современных условиях компании перестраивают свои бизнес-процессы примерно раз в два года, столько же требуется (если работать в традиционной технологии) для создания АИС. Может оказаться, что к моменту сдачи АИС она уже никому не нужна, поскольку компания, ее заказавшая, вынуждена перейти на новую технологию работы. Следовательно, для создания АИС жизненно необходим инструмент, значительно (в несколько раз) уменьшающий время разработки АИС.

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

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

Интерфейс AllFusion PM 7.2.

AllFusion PM имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать и анализировать сложные модели при минимальных усилиях. Ниже будет описан интерфейс версии 7.2 (рис. 3).

Приложение AllFusion PM имеет стандартный пользовательский интерфейс Windows. Вид окна приложения AllFusion PM представлен на рисунке 1. Окно AllFusion PM включает следующие элементы:

· Область системного меню,

· Стандартную панель инструментов,

· Панель инструментов AllFusion Model Manager (Services Toolbar),

· Область для рисования диаграмм,

· Строку текущего состояния (Status bar).

· Навигатор модели (Model Explorer),

· Панель инструментов AllFusion PM,

Системное меню предоставляет доступ ко всем функциям AllFusion PM. Стандартная панель инструментов обеспечивает быстрый вызов часто выполняемых задач моделирования. Панель инструментов AllFusion Model Manager предназначена для выполнения повседневных задач и задач администрирования единого репозитория моделей AllFusion Model Manager (не требуется, если модели сохраняются как файлы *.bp1,.а не в репозитории AllFusion Model Manager). Область для рисования диаграмм предназначена для создания и редактирования диаграмм модели. Строка текущего состояния (Status bar) содержит информацию об открытом окне приложения: опциях меню, кнопках инструментов и т.п. Навигатор модели (Model Explorer) позволяет представить иерархию работ и диаграмм в удобном и компактном виде. Панель инструментов AllFusion PM включает инструменты для рисования объектов в области диаграмм. Панель инструментов AllFusion PM является контекстно-зависимой, т.е. изменяется автоматически при переключении между нотациями моделирования, поэтому будет рассмотрена позднее в разделах, посвященных построению диаграмм в конкретных нотациях: IDEF0, IDEF3, DFD. Все панели инструментов, а также окно навигатора модели являются перемещаемыми. При наведении курсора на пиктограмму инструмента в панели инструментов появляется краткая подсказка; детальную информацию можно найти в меню Help.

Рис. 3.

Состав и описание функций стандартной панели инструментов представлено в таблице 1. Все функции стандартной панели инструментов доступна также из основного меню AllFusion PM.

Таблица 1. Описание элементов управления стандартной панели
инструментов AllFusion PM 7.2.

Элемент управления	Описание	Соответствующий пункт меню
	Создать новую модель	File/New
	Открыть модель	File/Open
	Сохранить модель	File/Save
	Напечатать модель	File/Print
	Запуск встроенного построителя отчетов Report Template Builder	Tools/Report Builder
	Выбор масштаба	View/Zoom
	Масштабирование	View/Zoom
	Проверка правописания	Tools/Spelling
	Включение/выключение навигатора модели Model Explorer	View/Model Explorer
	Включение/выключение панели инструментов для работы с AllFusion Model Manager	View/Services Toolbar

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

Русификация AllFusion PM.

В версии 7.2 русифицировать можно рамку (бланк) диаграмм, а также все тексты, вводимые пользователем.

Для русификации рамки диаграммы следует перед установкой продукта сохранить файл BPwinLoc.ini[1] в каталог C:\Windows.

Для русификации пользовательских текстов можно применять разные способы. Первый заключается в корректировке ключа системного реестра Windows HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control / Nls / CodePage: для параметров 1250 и 1252 требуется установить значение «c_1251.nls». Этот способ - самый быстрый, т.к. не требует настройки шрифтов для каждого типа объектов модели. Однако, для правки указанного ключа системного реестра требуются права администратора.

Второй способ может быть применен обычным пользователем, и заключается в настройке шрифтов по умолчанию для каждого типа объекта. Для этого следует выбрать пункт меню «Model/Default Fonts», после чего появляется меню, в котором перечислены типы объектов, для которых можно настроить значения шрифтов по умолчанию:

· Context Activity – название работы на контекстной диаграмме;

· Context Arrow – название стрелки на контекстной диаграмме;

· Decomposition Activity – название работы на диаграмме декомпозиции;

· Decomposition Arrow – название стрелки на диаграмме декомпозиции;

· Node Tree Text – текст на диаграмме дерева узлов;

· Frame User Text – текст, вносимый пользователем в рамке диаграмм;

· Frame System Text – системный текст в рамке диаграмм;

· Text Blocks – текстовые блоки;

· Parent Diagram Text – текст родительской диаграммы;

· Parent Diagram Title Text – текст заголовка родительской диаграммы;

· Report Text – текст отчетов.

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

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

Этапы построения модели.

Можно выделить следующие этапы построения модели.

1. Определение контекста модели, включая:

· определение границ системы,

· выбор цели,

· определение точки зрения.

2. Создание контекстной диаграммы (А-0).

3. Создание первой декомпозиции - диаграммы А0.

4. Анализ и корректировка диаграмм А-0, А0.

5. Создание диаграмм декомпозиции и их экспертиза.

6. Анализ модели, рекомендации по использованию модели.

Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель (рис. 12).

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

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

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

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

· Что может получить читатель модели?
(Для чего будет использоваться?)

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

Таблица 3. Пример формулирования цели моделирования.

№	Цель	Составляющие
1.	Анализ требований и проектирование спецификаций разрабатываемой корпоративной информационной системы для автоматизирования процессов производства.	Почему процесс моделируется? – (Провести) анализ требований разрабатываемой корпоративной ИС. Что показывает модель? – Спецификацию (описание подсистем, функций и условия их взаимодействия) системы. Для чего будет использоваться? - Для автоматизирования процессов производства.
2.	Упорядочивание информационных потоков (в том числе документооборота) внутри предприятия для выявления «узких мест» в документообороте и работе персонала.	Почему процесс моделируется? – Упорядочивание информационных потоков. Что показывает модель? – Информационные потоки. Для чего будет использоваться? - Выявление «узких мест» в документообороте и работе персонала.
3.	Формирование, на основании анализа процессов производства, рекомендаций по изменению организационно-управленческой структуры для оптимизации системы организационного управления.	Почему процесс моделируется? – (Необходимо) формирование предложений по реализации организационно-управленческой структуры. Что показывает модель? – Организационно-управленческую структуру. Для чего будет использоваться? – Для оптимизации системы организационного управления.

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

Контекстная диаграмма является вершиной древовидной структуры диаграмм (рис. 12). Она представляет собой общее описание системы и ее взаимодействия с внешней средой. Кроме этого на контекстной диаграмме рекомендуется размещать цель моделирования, точку зрения, иногда на диаграмму выносят также описание субъекта моделирования. Контекстная диаграмма имеет условное название (А-0).

После описания в целом проводится разбиение системы на крупные фрагменты. Этот процесс называется декомпозицией. Диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. Первая диаграмма декомпозиции имеет условное название А0 (рис. 12).

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

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

Завершается процесс моделирования анализом модели и написанием рекомендации по ее использованию.

Для обеспечения итеративного характера рецензирования и для обеспечения обратной связи при построении модели рекомендуется использовать так называемый цикл IDEF-папки (рис. 13, 14). В Приложении B дано описание цикла IDEF-папки в методологии IDEF3.

Контрольные вопросы:

1. Перечислите этапы построения модели в AllFusion PM.

2. Что такое «цель», «точка зрения», «субъект» моделирования?

3. Что такое «контекстная диаграмма»? Назовите состав контекстной диаграммы.

4. Что такое «диаграмма декомпозиции»? Чем определяется количество уровней декомпозиции?

5. Расскажите о процессе моделирования с использованием методологий IDEF.

6. Расскажите об итеративном процессе рецензирования моделей (цикл IDEF-папки).

Рис. 13.

Рис. 14.

Состав IDEF0-модели.

Модель, выполненная в методологии IDEF0, может содержать четыре типа диаграмм:

· контекстную диаграмму;

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

· диаграммы дерева узлов (будут рассмотрены позднее);

· FEO-диаграммы (будут рассмотрены позднее).

Состав IDEF0-диаграммы.

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

Работы (Activity).

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

При создании новой IDEF0-модели (меню «File/New») автоматически создается контекстная IDEF0-диаграмма с единственной работой, изображающей систему в целом. Примеры фрагментов контекстных диаграмм представлены на рис. 28 и 29.

Рис. 28.

Затем контекстная работа декомпозируется одним из указанных выше способов. Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему. Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу располагается самая важная работа или работа, выполняемая по времени первой. Далее правее вниз располагаются менее важные или позже выполняемые работы. Такое расположение облегчает чтение диаграмм, а, кроме того, на нем основывается понятие взаимосвязей работ. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу (рис. 28, 29, 30, 31). В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 28 работа "Изготовление изделия" не была еще декомпозирована, а на рис. 29 работа "Контроль качества" уже имеет нижний уровень декомпозиции. Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована.

Пример диаграммы декомпозиции для контекстной диаграммы "Изготовление изделия" приведен на рис. 30, а для контекстной диаграммы "Деятельность компании дистрибьютора" - на рис. 31.

Рис. 29.

Рис. 30.

Рис. 31.

Стрелки (Arrow).

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

В IDEF0 различают пять основных типов стрелок:

· Вход (input) – материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 28 – это нечто, что перерабатывается в процессе работы «Изготовление изделия» для получения результата. При моделировании информационной системы (ИС), когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при работе "Прием пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны, например, на выходе – "Заполненная карта пациента". Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может быть следующее, перерабатываются (изменяются) ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет – управление.

· Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 28 стрелки "Задание" и "Чертеж" – управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется ею. Если цель работы – изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

· Выход (Output) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 28 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".

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

· Вызов (Call) – специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В AllFusion PM стрелки вызова используются в механизме слияния и разделения моделей (см. Главу 5. Слияние/расщепление моделей для организации одновременной работы).

В AllFusion PM существует и другие классификации стрелок. Существует деление стрелок на:

· граничные и внутренние стрелки,

· связанные и несвязанные граничные стрелки,

· явные и неявные стрелки,

· разветвляющиеся и сливающиеся стрелки.

Рассмотрим эти разновидности стрелок.

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

1. Щелкнуть по кнопке с символом стрелки в палитре инструментов и перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

2. Щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);

3. Щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать пункт «Name» и добавить имя стрелки в закладке «Name» диалога «Arrow Properties».

Стрелки управления, вызова, механизма и выхода изображаются аналогично. Для рисования стрелки выхода, например, следует щелкнуть по кнопке с символом стрелки в палитре инструментов, щелкнуть в правой части работы со стороны выхода (где начинается стрелка), перенести курсор к правой стороне экрана, пока не появится начальная штриховая полоска, и щелкнуть один раз по штриховой полоске. Имена вновь внесенных стрелок автоматически заносятся в словарь стрелок AllFusion PM (Arrow Dictionary).

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

Содержимое словаря стрелок можно распечатать в виде отчета (меню «Report/Arrow Report...») и получить тем самым толковый словарь терминов предметной области, использующихся в модели.

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