Отличия между диаграммой dfd и idef 0

Модель, возможности

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

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

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

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

Описание модели, возможности (2)

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

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

Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ER-диаграмм.

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

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

Нотация DFD включает всего лишь 4 основных элемента: процесс, внешняя сущность, хранилище данных и поток данных.

Существуют два варианта графического отображения этих элементов: Юрдана (Yourdon) и Гейна-Сарсона (Gane-Sarson).

Основные ошибки при разработке DFD-диаграмм

1. Отсутствие контекстной диаграммы

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

Однако построение контекстной диаграммы необходимо! При помощи контекстной диаграммы мы определяем границы и объем будущей проектируемой системы.

## Контекстная диаграмма

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

## Неименованные потоки данных

Ещё одна часто встречающаяся ошибка — отсутствие названий у входящих и исходящих потоков. Каждая стрелка на схеме должна иметь название.

## Отсутствие процессов

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

## Отсутствие внешних сущностей

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

## Путаница между хранилищами и потоками данных

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

## Стремление показать логику выполнения процессов

DFD – это нотация, предназначенная для моделирования структуры информационной системы, но не её логики. Поэтому будет ошибкой привязывать элементы DFD-диаграммы к временным шкалам или использовать условные операторы XOR, OR, AND.

## Некорректное название элементов нотации

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

## Отсутствие выходов у процессов

Функциональное моделирование помогает рассматривать бизнес-модель с точки зрения результативности. При моделировании системы мы исходим из того, что имеем на входе, и того, что желаем получить на выходе. Иными словами, процесс — это действие с заданным результатом. В DFD хорошей практикой считается визуально располагать сущности одного типа на одном уровне, обычно по горизонтали. Тогда становится очевидным правило для процесса один вход — один выход.

## Источники для написания статьи

## Что такое DFD?

Data Flow Diagrams (DFD) – Графический Анализ Потоков Данных

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

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

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

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

Один из таких инструментов – DFD (Data Flows Diagrams) — диаграммы потоков данных.

Data Flow Diagrams (DFD)

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

Аккуратная и четкая DFD может графически отобразить значительную часть требований к системе. Она может быть ручной, автоматизированной или сочетать оба способа.

Цель DFD

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

Преимущества DFD

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

Пример использования DFD

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

Так родилась первая модель, представляющая собой потоковую диаграмму – предвестник DFD.

Преимущества Диаграммы Потоков данных (DFD)

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

Бизнес-уровень

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

Уровень системы

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

Движение данных

Теперь давайте поговорим о движении данных. Потоки данных мы встречаем не только в задачах, но и в повседневной жизни.

Примеры потоков данных:

• Документооборот
• Товарооборот
• Финансовые транзакции

Схема финансовой транзакции:

![](https://www.antonpiskun.pro/wp-content/uploads/2023/04/noroot.webp)

Процессы

Процессы в DFD идентифицируются с помощью номеров. Они описываются в виде предложений с глаголом в неопределенной форме в поле имени процесса. Например: Напечатать адрес получателя, Акцептовать счет. Информация о том, кто выполнит процесс, указывается в нижнем поле символа процесса.

Накопители данных

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

Пример DFD-диаграммы

Процесс: Получение суммы наличными по кредитной карточке

Сообщения о выдаче сумм наличными Данные о кредитной карточке клиента 1.1 Клиент Клиент банка банка Сумма наличными Выдать клиенту сумму наличными Служащий Служащий банка банка Протокол обслуживания терминал банка (банкомат) Запрос о состоянии текущего счета клиента D1 Данные по текущему счету клиента База данных счетов

Пример 3. Отгрузка товара клиенту (пошаговый)

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

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

Давайте разложим этот процесс на процессы нижнего уровня используя:

Действие Правило 1 “Глагол-объект” Правило 2 “Преобразующие действия” Правило 3 “Область действия” Внутренний процесс

Клиент начинает активность Триггер активности Нет Снаружи Нет

мы обрабатываем заказы, жалобы и платежи Отправка документов Нет Внутри Нет

Поступление заказа Обработка почты Да Внутри Да

мы подтверждаем кредитный лимит клиента Валидация кредитного лимита Да Внутри Да

мы подтверждаем наличие Подтверждения наличия товаров Да Внутри Да

Подтверждение заказа Аккумулирование подтвержденных заказов Нет Внутри Нет

и группировка по зонам отправки Группировка заказов Да Внутри Да

Передача на склад Передача подтвержденных заказов Нет Внутри Нет

Заказ выполнен Выполненный заказ ? Снаружи Нет

После проведения анализа мы выяснили, что с заказами связано 4 внутренних процесса организации:

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

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

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

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

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

Диаграмма 1-го уровня иерархии

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

Пример 2. Обработка заявки клиента

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

Последовательность получается такая:

С точки зрения DFD у нас имеются:

Контекстная диаграмма для этого процесса будет следующая:

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

Анна Евгеньевна Терехова

Детализация DFD-диаграмм

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

Пример 1. Приготовление кофе в кофейном автомате

Как происходит процесс приготовления кофе в кофейном автомате.

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

Пример DFD: приготовление кофе в кофейном автомате. Контекстная диаграмма

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

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

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

Когда заказ оплачен, ингредиенты и рецепт передаются в процесс Приготовить кофе. Готовый напиток наливается в стаканчик, переданный из Склада стаканов. Это происходит в процессе Налить кофе. В результате клиент получает готовый напиток.

С помощью чего рисовать диаграммы

Можно рисовать DFD-диаграммы, используя привычные вам инструменты. Для этого подойдут, например, всем известные MS Visio или Draw.io. Но для выстраивания системы с разными уровнями детализации потребуются специализированные программы для моделирования.

Существует множество редакторов для построения DFD-диаграмм. Самым популярным является Ramus. Этот продукт имеет бесплатную версию, доступен в сетевом и локальном вариантах. StarUML — проект с открытым кодом, ещё один ходовой инструмент для создания диаграммы потоков данных. Для командной работы можно использовать облачное решение Lucidchart.

Контекстная диаграмма потоков данных

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

Внешние сущности

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

Миниспецификации обработки

Миниспецификации обработки описывают DFD-процессы нижнего уровня и являются базой для кодогенерации. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификации является полной спецификацией системы. Миниспецификации содержат номер и/или имя процесса, списки входных и выходных данных, тело (описание) процесса, собственно и являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса, соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа FLOW-форм и диаграмм НассиШнейдермана) и формальных компьютерных языков.

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

Правил для построения не так уж и много:

Контекстная диаграмма в нотации Йордана де Марко

Контекстная диаграмма содержит три основных компонента:

DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме.

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

Ограничения модели

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

DFD (Data Flow Diagram)

Модель системы определяется как иерархия диаграмм потоков данных, описывающих процессы преобразования информации от момента ее ввода в систему до выдачи конечному пользователю. Диаграммы верхних уровней иерархии – контекстные диаграммы, задают границы модели, определяя её окружение (внешние входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются при помощи диаграмм следующих уровней. Диаграмма потоков данных (data flow diagram, DFD) – один из основных инструментов структурного анализа и проектирования информационных систем, существовавших в "доюмээльную" эпоху.

Спасибо за внимание!

Ваши вопросы, пожалуйста ..

Действие Правило 1 “Глагол-объект” Правило 2 “Преобразующие действия” Правило 3 “Область действия” Внутренний процесс

Клиент начинает активность Триггер активности Нет Снаружи Нет

мы обрабатываем заказы, жалобы и платежи Отправка документов Нет Внутри Нет

Поступление заказа Обработка почты Да Внутри Да

мы подтверждаем кредитный лимит клиента Валидация кредитного лимита Да Внутри Да

мы подтверждаем наличие Подтверждения наличия товаров Да Внутри Да

Подтверждение заказа Аккумулирование подтвержденных заказов Нет Внутри Нет

и группировка по зонам отправки Группировка заказов Да Внутри Да

Передача на склад Передача подтвержденных заказов Нет Внутри Нет

Заказ выполнен Выполненный заказ ? Снаружи Нет

Иерархия диаграмм потоков данных

Диаграммы потоков данных строятся по иерархическому принципу. Структура иерархии DFD диаграмм показана на рисунке. Контекстная диаграмма верхнего уровня определяет границы модели.

Потоки данных

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

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

Элементы DFD-диаграмм

Основными элементами DFD являются: внешние сущности; процессы; накопители данных; потоки данных. DFD методология не оформлена как стандарт. По этой причине в диаграммах потоков данных используются различные условные обозначения. Исторически сложилось так, что для описания диаграмм DFD используются две нотации – Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.