Использование DFD: как описать движение данных
в бизнес-процессах

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

В статье мы

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

Вы узнаете достоинства и недостатки DFD-нотации по сравнению с другими методами бизнес-моделирования (IDEF0, BPMN, EPC, UML), поймёте ключевые принципы и инструменты их разработки.

Не любите читать? Посмотрите видео

С потоками данных мы сталкиваемся не только при решении IT-задач, но и в реальной повседневной жизни.

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

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

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

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

Наиболее актуальный жизненный пример движения данных — это вакцинация от коронавируса. В пункте вакцинации мы предоставляем данные паспорта, медицинского полиса и СНИЛС. Медицинский работник вписывает в рабочий журнал представленные нами сведения, дату прививки и данные о вакцине. Затем сведения вносятся в Регистр вакцинированных от COVID-19. Оттуда данные передаются в Госуслуги, где мы можем скачать личный QR-код.

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

Задача состояла в том, чтобы оптимально разместить определённое количество сотрудников в одном месте и сократить излишнюю арендную плату.

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

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

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

Сквозная аналитика по веб-рекламе. Например, мы запустили рекламу на Google Ads, в Яндекс.Директ и через SEO. Из всех источников собираем данные о просмотрах рекламных объявлений и кликах, а затем передаем все эти данные в единую систему аналитики. Также в систему аналитики передаются сведения из CRM о том, откуда именно пришёл клиент.

Ещё один хороший кейс — анализ конверсии сайта. Я получала заявки из CRM-системы в виде CSV-файлов и данные из Google Adwords в этом же формате. Для проверки гипотезы, как связано количество посещений (DAU-метрика) с заявками в этот день, даже пришлось вручную написать небольшой Python-скрипт. Визуализацию результатов можно сделать в дашборде BI-системы или комплексном инструменте аналитики (например, Google Data Studio).

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

Обычно такие задачи возникают:

• в проектах управления данными (Data Management)
  
• при интеграции информационных систем
  
• в проектах внедрения систем электронного документооборота
  

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

Проектирование DFD-диаграмм охватывает 3 уровня абстракции:

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

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

3. Диаграмма физических потоков данных моделирует хранилища данных: принтеры, формы, устройства и другие проявления данных.

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

Структурный анализ — метод исследования системы, который начинается с её общего обзора, а затем иерархически детализируется по уровням абстракции. Иными словами, структурный анализ предполагает, что мы идем от общего к частному, разбивая систему как «черный ящик» на множество «черных ящиков», последовательно приближаясь к результату.

Результат фиксируется с использованием строгих правил записи в соответствии с алфавитом нотации и правилами использования элементов этого алфавита.

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

Принципы структурного анализа:

• «разделяй и властвуй»
  
• иерархическая упорядоченность
  
• решение проблем через их разделение на множество независимых задач — «черных ящиков»

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

Исторически синтаксис DFD-нотации применяется в двух вариантах: Йордона-Де Марко и Гейна-Сарсона.

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

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

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

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

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

Рассмотрим в качестве примера выдачу кредита физическому лицу.

1. Клиент подаёт заявку на кредит.
2. Банк оценивает платежеспособность и надежность клиента.
3. С учетом полученных сведений и на основании истории взаимоотношений с клиентом банк принимает решение о выдаче кредита. Решение содержит данные о выдаваемой сумме и процентной ставке.
4. Банк создаёт кредитный счёт и перечисляет на него деньги.

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

Самая важная для проектирования информация содержится внутри процессорного блока. Его содержимое раскрывается в декомпозированной DFD-диаграмме.

Что можно увидеть на этой DFD-диаграмме?

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

Клиент как внешняя сущность передаёт сведения о своих доходах. Эти данные помещаются в промежуточное хранилище Справка о доходах.

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

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

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

Из Кредитного счёта в процесс Выдача денег поступает поток денежных средств. Результатом финального процесса является выдача кредита клиенту.

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

1. Клиент задаёт машине параметры заказа, вносит в автомат деньги.
2. Автомат обменивается данными с внешней системой банковского эквайринга, посылая счёт на оплату.
3. Система возвращает чек за покупку.
4. Аппарат выдаёт кофе клиенту.

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

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

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

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

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

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

В качестве третьего примера давайте рассмотрим систему по предоставлению пользователю контента с учетом его интересов. Контент поступает по каналам, которые предпочел клиент: это может быть telegram, любой другой мессенджер или просто email.

Как выглядит процесс?

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

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

При этом система сама будет определять, что нравится пользователю, а что не нравится.

Рассмотрим декомпозированную DFD-диаграмму, составленную для этого примера.

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Отсутствие процессов

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

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

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

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

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

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

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

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

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

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

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