Лекция №7, Обследование предметной области

« Назад

 

1. Описание предметной области. Реинжиниринг бизнес-процессов

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

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

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

Таблица 1

Традиционная макроуровневая классификация ресурсов

Классы ресурсов	Виды ресурсов
Трудовые	рабочие служащие
Материальные	станки сырье материалы изделия
Финансовые	деньги акции
Нематериальные	информация знания

Функционирование ЭС реализуется посредством взаимодействия ее элементов. Обычно, это взаимодействие локализуется в рамках определенного процесса. Например, при производстве изделий взаимодействуют элементы СПЕЦИФИКАЦИИ, РАБОЧИЕ, МАТЕРИАЛЫ, ОБОРУДОВАНИЕ, в результате чего получается ИЗДЕЛИЕ (рис. 1). Число изделий, произведенных за день, является свойством процесса, но никак не характеризует ни одного из участвующих в нем элементов, взятых в отдельности.

Рис. 1 - Процесс производства

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

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

Различают неформатированные и форматированные сообщения.

Неформатированные сообщения - это сообщения на естественном языке. Например:

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

Таблица 2

Пример форматированного сообщения

Название параметра	Значение параметра
Получатель Отправитель Изделие Дата Цена Количество	Склад №2 фирма «Форс» компьютер Pentium 23.09.06 30 000 рублей 50 штук

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

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

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

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

Информационная модель может быть воплощена в одной или нескольких базах данных.

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

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

Бизнес-процесс – это преобразование одного набора ресурсов в другой.

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

Бизнес-процессы обычно подчиняются некоторым стандартам. Но при автоматизации появляются новые бизнес-процессы или происходит усовершенствование существующих.

При автоматизации бизнес-процессов компании придерживаются одной из двух стратегий:

1. Настройка или создание программного продукта под существующие в организации бизнес-процессы.

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

2. Реинжиниринг БП – структура и характер бизнес-процессов в организации подстраивают под программный продукт.

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

Впервые термин "реинжиниринг бизнес-процессов" (от англ. business process reengineering, BPR) был введен Майклом Хаммером в 1990г., который определяет этот вид деятельности как "фундаментальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных актуальных показателях их деятельности: стоимость, качество, услуги и темпы". За несколько лет реинжиниринг превратился в одну из ведущих и активно развивающихся отраслей информатики.

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

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

2. Реинжиниринг призван обеспечить мощный рост результативности, осуществить серьезный прорыв.

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

Основные принципы реинжиниринга

1. Объединение нескольких рабочих процедур в одну;

2. Принятие исполнителями самостоятельных решений;

3. Выполнение работ там, где это целесообразно;

4. Уменьшение количества проверок и управляющих воздействий;

5. Минимизация количества согласований;

6. Переход от оценки деятельности к оценке результата;

7. Переход от удовлетворения потребностей производства к удовлетворению потребностей клиентов.

Причинами неудач могут быть:

1) недостаточно четкое понимание задачи;

2) слабая мотивация;

3) неактивная позиция руководства;

4) недостаточно твердая методологическая основа.

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

Реинжиниринг бизнес-процессов в компании "IBM Credit" привел к росту производительности труда в 100 раз и уменьшению времени процессов в 10 раз. При проведении реинжиниринга в компании "Ford", численность отдела по оплате счетов поставщиков сократилась с 500 человек до 125, т.е. производительность повысилась в 4 раза. В третьем примере проведения реинжиниринга бизнес-процесса проектирования новой фотокамеры в компании "Kodak" были достигнуты результаты по сокращению времени процесса в два раза.

Поэтому можно считать, что границами реинжиниринга являются следующие величины улучшений – 2, 4, 10 и более раз или 50%, 75%, 90% и более процентов, отсчитываемые от начала процесса реинжиниринга. В случае постоянного совершенствования улучшение показателей составляет 5 – 20 %. Что касается временного периода, в рамках которого приведенные улучшения были достигнуты, то он составляет 6 – 12 месяцев.

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

2. Моделирование бизнес-процессов

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

Структурная модель характеризует морфологию системы (ее построение) – состав подсистем, их взаимосвязи.

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

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

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

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

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

- SADT – модели, состоящие из серии функциональных диаграмм, фрагментов текстов, глоссария и ссылок друг на друга (основа для методологии IDEF0);

- DFD – диаграммы потоков данных;

- ERD – диаграммы «сущность-связь» (методология IDEF1).

Методология SADT разработана Дугласом Россом. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Методология применима для реорганизации хорошо специфицированных и стандартизированных бизнес-процессов, поэтому на Западе принята в качестве типовой. Основные элементы этой методологии основываются на следующих концепциях:

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

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

Правила SADT включают:

- ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков); SA-блок выглядят следующим образом:

Рис. 2 - Функциональный SA-блок и интерфейсные дуги

- связность диаграмм (номера блоков);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков и дуг);

- разделение входов и управлений (правило определения роли данных);

- отделение организации от функции, т.е. исключение влияния - организационной структуры на функциональную модель.

Рис. 3 - Пример SA-блока. Представление технологической операции проектирования

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

IDEF0 – методология функционального моделирования. Первый этап изучения любой системы. Ответ на вопрос «Что делает система?».

IDEF1 – методология моделирования информационных потоков внутри системы, их структура и взаимосвязи (на основе DFD).

IDEF2 – методология динамического моделирования развития систем. Из-за своей сложности их развитие приостановилось Заменен на превращение статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри».

IDEF3 – методология используется для описания последовательности операций для каждого процесса на предприятии. Имеет тесную связь с IDEF0: каждый функциональный блок может быть представлен в виде отдельного процесса средствами IDEF3. Ответ на вопрос «Как система это делает?».

IDEF4 – методология построения объектно-ориентированных систем.

IDEF6 – направлена на сохранение рационального опыта проектирования АИС для предотвращения возникновения повторных ошибок.

IDEF9 – проектирование диалога человека с системой.

IDEF14 – моделирование вычислительных сетей.

3. CASE-средства, применяемые для построения моделей бизнес-процессов

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

Технология проектирования с использованием CASE-средства определяется как совокупность трех составляющих:

- пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1);

- критериев и правил, используемых для оценки результатов выполнения технологических операций;

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

CASE-средства (от Computer Aided Software/System Engineering) как необходимый элемент системного и структурно-функционального анализа, позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций, создавать документацию. Применимы практически во всех сферах деятельности. Результат применения CASE-средств – оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

- Business Studio;

- Designer/2000, S-Designer;

- ERwin+BPwin;

- CASE-Аналитик;

- Rational Rose.

Связь BPwin с ERwin (моделирование данных в стандарте IDEF1) позволяет сократить время проектирования и разработки сложных информационных систем. ERwin имеет два уровня представления модели – логический и физический. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных – это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. Для системных аналитиков тесная интеграция BРwin с инструментом проектирования баз данных открывает уникальные возможности по созданию комплексных систем, в которых ERwin служит для описания информационных объектов системы, в то время как BPwin отражает функциональные особенности предметной области. СASE-средство Rational Rose предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках объектно-ориентированного программирования и для выпуска проектной документации.

Система Model Mart является хранилищем моделей, к которому открыт доступ для участников проекта создания ИС. Model Mart удовлетворяет всем требованиям, предъявляемым к средствам разработки крупных ИС, а именно:

1. Совместное моделирование. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время.

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

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

4. Основные элементы и понятия IDEF0, DFD, IDEF3

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

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

BPwin может генерировать отчеты непосредственно в формате MS Excel и Word для последующей обработки и использования в других приложениях.

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

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

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

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

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

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

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

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

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

Результатом применения методологии IDEF0 является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. И контекстная диаграмма и диаграммы декомпозиции состоят из SA-блоков.

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

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

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

Рис. 4 - Пример обратной связи

Стрелки, указанные на контекстной диаграмме, автоматически появляются на диаграммах нижнего уровня. Вновь внесенная стрелка на диаграмме декомпозиции нижнего уровня изображается в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня. Для их "перетаскивания" наверх нужно сначала щелкнуть по квадратным скобкам граничной стрелки. Появляется окно «Border Arrow Editor». Если щелкнуть по кнопке «Resolve Border Arrow», стрелка мигрирует на диаграмму верхнего уровня. Если щелкнуть по кнопке «Change To Tunnel», стрелка будет эатоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце. Тоннелирование может быть применено для изображения малозначимых стрелок.

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

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.

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

Всего в DFD используется четыре важных элемента:

- Работы.

- Стрелки (потоки данных).

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

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

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

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

Методика IDEF3 отражает поведенческие аспекты приложений. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос "Что делает система?", то IDEF3-модель отвечает на вопрос "Как система это делает?". При этом в IDEF3 детализируются и конкретизируются IDEF0-функции.

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

Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. 

Рис. 5 - Типы перекрестков (дискретная математика)

Все дуги в IDEF3 могут сливаться и разветвляться только через перекрестки.

Объекты ссылок выражают некоторую концепцию или данные, которые нельзя обозначить другими элементами (н-ер, «Программное обеспечение», «Склад»). С работами соединяются дугами без наконечников.