Как составить dfd диаграмму

Время на прочтение
3 мин

Количество просмотров 46K

Привет всем!

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

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

Зачем нужны DFD диаграммы?

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

• при разработке информационной системы;

• при интеграции системы;

• при миграции данных и функционала с одной системы на другую;

• в проектах, связанных с Data Management;

• в процессе построения аналитического хранилища, BI-решения.

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

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

Выделяют 4 элемента в диаграмме:

1. Процесс.

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

2. Внешняя сущность.

   Сущность (объект), которая получает или отправляете данные при взаимодействии с описанным процессом. 

3. Хранилище данных.

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

4. Поток данных.

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

Несколько правил построения диаграмм:

• Процесс должен иметь входной и выходной поток данных.

• Хранилища данных также должны иметь входные и выходные потоки данных.

• Данные с внешних сущностей должны обязательно проходить через процесс чтобы попасть в хранилище.

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

Уровни DFD Диаграммы

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

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

• Концептуальный (или контекстный) уровень.

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

• Логический уровень.

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

• Физический уровень.

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

Также часто в других источниках можно увидеть разделение уровней диаграммы на 0,1, 2, 3 и так далее, в зависимости от уровня детализации.

Если мы говорим про разработку нового решения, то важно понять “что мы имеем сейчас” (AS-IS) и “что мы желаем получить” (TO-BE). Другими словами, мы разделяем наше текущее состояние и желаемое состояние, которое мы хотим получить с помощью нашего решения. 

AS-IS 

Описываем текущую логическую диаграмму.

TO-BE 

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

Telegram канал про аналитику данных и бизнес-анализ

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

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

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

Почему ДФД?

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

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

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

Вот преимущества метода DFD:

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

DFD против блок-схемы

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

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

Элементы ДПД

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

• Процессы . Действия и действия, выполняемые с данными, представлены круглыми или круглыми прямоугольниками.

• Хранение данных . Существует два варианта хранения данных — это может быть представлено как — 1. Это может быть представлено в виде прямоугольника без двух маленьких ребер, 2) или в виде открытого прямоугольника только с одним краем
  . Открытый прямоугольник с отсутствующими ребрами.

• Поток данных — движение данных представлено острыми стрелками. Движение данных показано как движение от нижней части стрелки в качестве источника к острию стрелки в качестве пункта назначения.

Пример потока данных — электронный банкинг

Менеджер банка предоставляет новые сведения об учетной записи открытому процессу учетной записи, в результате чего сведения о клиенте хранятся в хранилище данных базы данных клиентов, а сведения об учетной записи — в хранилище данных базы данных учетных записей. Хотя мы используем слово «результат» в нашей интерпретации, DFD не подразумевает причинно-следственной связи; Все, что он показывает, это то, что процесс открытия счета может считывать данные из интерфейса менеджера банка без записи данных в базу данных клиентов и хранилища данных базы данных счетов в определенном порядке.

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

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

Клиент может инициировать процесс перевода средств и должен указать адрес счета и сумму средств. Процесс перевода средств может отправить сумму средств в другой банк через интерфейс другого банка.

ОТРЕДАКТИРУЙТЕ ЭТОТ ПРИМЕР ДИАГРАММЫ ПОТОКА ДАННЫХ

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

Метод нисходящей декомпозиции — многоуровневые DFD

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

Чтобы сделать DFD еще более сложным (т. е. не слишком много процессов), вы можете создать многоуровневый DFDS.

• Контекстная диаграмма содержит управляющий (агрегированный) системный процесс.
• DFD более высокого уровня является менее подробным (более подробный DFD разрабатывается на нижнем уровне) и называется процессом декомпозиции сверху вниз.
• Контекстная диаграмма начинается с номеров процессов (например, процесс 1, процесс 2 и т. д.).
• Нумерация продолжается на следующем так называемом первом уровне (DFD). Например, процесс 1 на контекстной диаграмме уточняется до трех процессов в DFD первого уровня и имеет номера 1.1, 1.2 и 1.3.
• Аналогичным образом нумеруются процессы второго уровня, например 2.1.1, 2.1.2, 2.1.3 и 2.1.4. Нумерация процессов в иерархии:
  • (1, 2, 3,…);
  • (1.1, 1.2, 1.3,…, 2.1, 2.2, 2.3,…);
  • (1.1.1, 1.1.2, 1.1.3,…).
• Количество слоев зависит от размера модельной системы.

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

Пример DFD — система заказа еды

Контекстная диаграмма (уровень 0 — DFD)

Контекстная диаграмма показывает обзор системы и то, как она взаимодействует с другими частями «мира». Контекстная диаграмма — это диаграмма потока данных, которая показывает только верхний уровень, который называется уровнем 0. На этом уровне есть только один видимый узел процесса, который представляет функциональность всей системы, т. е. то, как она взаимодействует с внешними объектами. Вот некоторые из преимуществ контекстной диаграммы.

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

На рисунке ниже показана контекстная диаграмма (схема потока данных верхнего уровня), нарисованная для системы заказа еды.

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

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

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

ОТРЕДАКТИРУЙТЕ ЭТОТ ПРИМЕР DFD

Context DFD — это точка входа в модель потока данных. Он содержит один и только один процесс и не показывает никакого хранилища данных.

ДФД уровня 1

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

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

ОТРЕДАКТИРУЙТЕ ЭТОТ ПРИМЕР ДИАГРАММЫ ПОТОКА ДАННЫХ

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

1. По диаграмме мы знаем, что покупатель может оформить заказ. Процесс заказа продуктов питания получает заказ, пересылает его на кухню, сохраняет в хранилище данных заказов и сохраняет обновленные сведения об инвентаризации в хранилище данных инвентаризации. Процесс также обеспечивает выставление счетов клиенту.
2. Менеджеры могут получать отчеты с помощью процесса «Создать отчет», в котором сведения о запасах и заказах используются в качестве входных данных для хранилищ данных запасов и заказов соответственно.
3. Менеджер также может инициировать процесс инвентаризации заказа, предоставив заказ инвентаризации. Этот процесс пересылает заказ инвентаризации поставщику и сохраняет обновленные данные инвентаризации в хранилище данных инвентаризации.

Логический и физический DFD

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

Логический DFD

• Логический DFD показывает, как работает бизнес.
• Процессы представляют бизнес-операции.
• Хранилища данных представляют собой набор данных независимо от того, как они хранятся.
• Это то, как бизнес контролирует.

Физический DFD

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

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

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

Логический пример DFD — продуктовый магазин

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

ОТРЕДАКТИРУЙТЕ ЭТОТ ЛОГИЧЕСКИЙ ПРИМЕР DFD

Пример физического DFD — продуктовый магазин

• Физический DFD показывает, что используется штрих-код — код UPC PRICE, который можно найти на большинстве товаров в продуктовых магазинах.
• Кроме того, в физическом DFD упоминаются ручные процессы, такие как сканирование, поясняется, что временный файл используется для хранения промежуточного количества элементов.
• ОПЛАТА может быть произведена НАЛИЧНЫМИ, ЧЕКОМ или ДЕБЕТОВОЙ КАРТОЙ.

Наконец, это относится к квитанции по ее названию, КАССОВАЯ КВИТАНЦИЯ.

ОТРЕДАКТИРУЙТЕ ЭТОТ ФИЗИЧЕСКИЙ ПРИМЕР DFD

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

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

Ресурсы

• Что такое диаграмма потока данных (DFD)?
• Как создать диаграмму потока данных (DFD)?
• Программное обеспечение диаграммы потока данных (DFD)
• Примеры диаграмм потока данных

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

Что такое DFD-нотация и зачем она нужна

Хотя BPMN и EPC нотации позволяют отлично описать логику выполнения бизнес-процессов, о чем мы писали здесь и здесь, иногда требуется показать эту деятельность не с позиции совершаемых действий, а с точки зрения обрабатываемых данных. Иначе говоря, нужно ответить на вопросы, из каких источников данных приходят, как преобразуются и куда отправляются. Обычно такая задача возникает в проектах, связанных с управлением данными (Data Management) и интеграции информационных систем. Методы и способы интеграции ИС мы рассмотрим в другой раз, а пока сфокусируемся на описании движения потоков данных. Именно для этого и нужны DFD-диаграммы (Data Flow Diagram).

Подобно IDEF0, DFD-нотация относится к SADT-методологии и соответствует структурному подходу, поддерживая принципы декомпозиции, иерархической упорядоченности и смыслового разделения сущностей. Хотя DFD и не содержит логических операторов (XOR, AND, OR), которые мы разбирали здесь, а также имеет очень ограниченное число элементов, она отлично позволяет описать последовательность возникновения, изменения и преобразования данных через их движение между процессами и хранилищами. Существует 2 разновидности DFD-диаграмм (Гейна-Сарсона и Йордана-Де Марко), которые немного отличаются лишь обозначениями некоторых элементов.

Итак, DFD-диаграмма включает следующие компоненты:

• Процесс – функция или действия по обработке данных. Обозначается в виде круга или прямоугольника со скругленными краями и горизонтальной чертой внутри. Поскольку используется для описания действия, называется как глагол, например, «отправить заявку», «просмотреть документ» и пр.
• Внешняя сущность – объект за пределами моделируемой системы, который является отправителем или получателем данных – человек, внешний сервис, носитель информации, сторонний источник данных и пр. Обозначается квадратом. Поскольку является объектом, называется как существительное, к примеру, «Клиент», «Поставщик», «БД ГИБДД», «Госуслуги» и пр.
• Хранилище данных – источник, приемник или промежуточное хранилище данных внутри моделируемой системы – база данных, таблица, документ, список, файл и пр. Обозначается в виде прямоугольника с незакрытым правым краем, может иметь вертикальную черту слева. Поскольку является объектом, называется как существительное: «Список дел», «1С:Предприятие», «CRM-система», «Файл с данными заказов», «Заявка» и пр.
• Поток данных – непосредственно данные, которые входят в процессы и хранилища или выходят из них. Например, «ФИО клиента», «Номер договора», «Сведения по заявке», «Запрос» и т.д. Обозначаются как сплошные стрелки с подписями.

Правил для построения DFD-диаграмм совсем немного, и все они очень простые:

• потоки данных перемещаются между хранилищами через процессы. Рекомендуется также показывать промежуточные хранилища данных при их перемещении между процессами, однако на практике это нее всегда строго соблюдается.
• В отличие от IDEF0, не важно, с какой стороны стрелка входит в блок «процесс» или «хранилище данных», а также с какой стороны выходит. Поток данных, выходящий из процесса, является его выходом (результатом), а входящий – входом.
• Как и в IDEF0, разработка моделей в нотации DFD начинается с контекстной диаграммы, которая представляет собой 1 процессный блок и также может включать 1 или несколько внешних сущностей. Дальнейшая декомпозиция этого «черного ящика» выполняется на следующих уровнях иерархии, т.е. вложенных диаграммах.
• В отличие от процессно-событийных нотаций BPMN, EPC и UML activity, DFD не содержит логических операторов (XOR, AND OR).

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

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

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

1. пользователь проходит тест;
2. получает промокод из базы данных промокодов;
3. в базе обновляется статус промкода, например, из состояния «новый» он переходит в состояние «выданный»;
4. пользователь оставляет свой email на веб-странице с итогами теста, если хочет получить напоминание по электронной почте;
5. email пользователя добавляется в базу данных подписчиков;
6. для пользователя формируется мааркетинговое предложение в виде электронного письма с указанием промокода, данными о его сроке действия, размеру скидке и курсе, на который он распространяется (даты проведения, стоимость, pdf-файл программы);
7. сформированное письмо отправляется пользователю по электронной почте с указанным email-адресом;
8. пользователь переходит по ссылке в электронном письме для оплаты курса;
9. пользователь оплачивает курс со скидкой по промокоду (этот процесс подробнее рассмотрен в виде UML-диаграммы последовательности здесь);
10. после оплаты статус использованного промокода в базе промокодов меняется на «применен».

Таким образом, здесь можно выделить следующие хранилища данных:

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

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

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

• Методы описания бизнес-процессов (IDEF, BPMN, EPC, UML)
• Основы бизнес-анализа: вход в профессию для начинающих

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

DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Википедия

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

Для себя я вывел следующую формулировку:

DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.

Зачем нужна нотация DFD?

Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – в таблице ниже:

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

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

• Из чего состоит информационная система?
• Что нужно, чтобы обработать информацию?

Непосредственно DFD нотация состоит из следующих элементов:

• Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.
• Внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных.
• Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.
• Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы. Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес-процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных. Для работы с процессами я рекомендую использовать BPMN или IDEF3 (о ней я расскажу в другой раз).

Как создавать нотации DFD

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

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

1. Клиент предоставляет свои данные и заявку.
2. Менеджер проверяет и вносит полученные данные в систему.
3. Работник склада формирует документы, например, расходную накладную, и отгружает товар.
4. Клиент получает товар и пакет документов к нему.

Эту последовательность действий нам необходимо увидеть с точки зрения хранения данных и работы с ними в IT-системе.

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

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

Какие правила необходимо знать, чтобы создать DFD диаграмму:

• Каждый процесс должен иметь один вход и один выход. Смысл процессов здесь заключается в обработке данных, а потому процесс должен получить данные (входящая стрелка) и отдать куда-то после обработки (исходящая стрелка);
• Процесс обработки данных должен иметь внешнюю входящую стрелку (данные от внешней сущности). Для того, чтобы любой подобный процесс начал работать, мало использовать данные из хранилища, должна поступить новая информация для последующей обработки;
• Стрелки не могут связывать напрямую хранилища данных, все связи идут через процессы. Нет смысла просто перемещать данные из одного места в другое, а именно так читается прямая связь двух хранилищ стрелкой. Данные поступают для того, чтобы производились какие-то действия, в нашем примере – осуществлялся процесс продажи. А это возможно только посредством обработки (процесса);
• Все процессы должны быть связаны либо с другими процессами, либо с другими хранилищами данных. Процессы не существуют сами по себе, а потому результат должен куда-то передаваться;
• Декомпозиция. В DFD-диаграммах предусмотрена возможность создавать крупные процессы и декомпозировать их на подпроцессы с подробным описанием действий. Например, мы можем создать процесс «создание заявки», который потом декомпозировать на последовательность действий, например, на получение заявки, отдельно – проверку и получение данных клиента, если товар в интернет-магазине продается под заказ, то также при формировании заявки потребуется получить данные от поставщика о наличии нужных наименований и т.д. И тогда на верхней диаграмме у нас будет блок «обработка заявки», а при декомпозировании мы получим диаграмму с подробной последовательностью действий на этом этапе. При этом ни на одном этапе у нас не будет условий и ветвления. Будет процесс и его декомпозиция глубиной до 3-4 уровней.

Как будет выглядеть диаграмма (без декомпозиции, верхний уровень):

И декомпозиция основного элемента нашей диаграммы:

Где используются DFD нотации

DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:

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

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

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

DFD нотации – это просто!

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

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

Рисовать диаграммы DFD можно, в принципе, где и как вам удобнее. Но если вы хотите работать с декомпозицией, выстраивать систему на разных уровнях детализации, то «рисовалки» (Visio, Paint и тому подобные) придется забыть. Вам потребуются специализированные программы для моделирования.

Лично я пользуюсь программой ERwin и всем ее рекомендую. Одна из причин моего выбора – это особенности декомпозиции. В ERwin, как и в некоторых других подобных системах, существует возможность декомпозирования DFD-процессов в формате IDEF3, т.е. основная диаграмма будет в формате DFD, и на самом общем уровне вы будете видеть основные потоки данных и «узлы» их обработки. А при декомпозиции вы сможете использовать уже процессный подход, что также бывает очень удобно для разработки крупных систем или работе с разными подразделениями бизнеса.

Вопросы и ответы

В чем разница между DFD и UML?

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

Если вы — разработчик, и знаете UML, волне возможно, что даже какие-то предварительные решения вам будет удобнее создавать в этой нотации. А для бизнес-консультанта DFD всегда будет удобнее в качестве инструмента, так как бизнес-консультанту не требуется подробное описание функций с точки зрения автоматизации, это — задача технических специалистов. Зато время и силы DFD значительно экономит.

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

Какое количество элементов может использоваться в DFD?

В отличие от систем с жестким синтаксисом и регламентом, в DFD нет ограничения по количеству элементов, которые могут находиться на одной диаграмме. Для сравнения: в IDEF0 количество таких элементов , дальше — только детализация (декомпозиция) или разные нотации.

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

Можно ли использовать нотации DFD для работы с клиентами?

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