Рассмотрим еще одну нотацию моделирования, которая не часто используется для непосредственного описания бизнес-процессов, а потому редко применяется начинающими системными и бизнес-аналитиками. Читайте далее, что такое DFD-диаграмма, зачем она нужна и как ее использовать в проектах интеграции информационных систем и управления данными.
Что такое DFD-нотация и зачем она нужна
Хотя BPMN и EPC нотации позволяют отлично описать логику выполнения бизнес-процессов, о чем мы писали здесь и здесь, иногда требуется показать эту деятельность не с позиции совершаемых действий, а с точки зрения обрабатываемых данных. Иначе говоря, нужно ответить на вопросы, из каких источников данных приходят, как преобразуются и куда отправляются. Обычно такая задача возникает в проектах, связанных с управлением данными (Data Management) и интеграции информационных систем. Методы и способы интеграции ИС мы рассмотрим в другой раз, а пока сфокусируемся на описании движения потоков данных. Именно для этого и нужны DFD-диаграммы (Data Flow Diagram).
Подобно IDEF0, DFD-нотация относится к SADT-методологии и соответствует структурному подходу, поддерживая принципы декомпозиции, иерархической упорядоченности и смыслового разделения сущностей. Хотя DFD и не содержит логических операторов (XOR, AND, OR), которые мы разбирали здесь, а также имеет очень ограниченное число элементов, она отлично позволяет описать последовательность возникновения, изменения и преобразования данных через их движение между процессами и хранилищами. Существует 2 разновидности DFD-диаграмм (Гейна-Сарсона и Йордана-Де Марко), которые немного отличаются лишь обозначениями некоторых элементов.
Итак, DFD-диаграмма включает следующие компоненты:
- Процесс – функция или действия по обработке данных. Обозначается в виде круга или прямоугольника со скругленными краями и горизонтальной чертой внутри. Поскольку используется для описания действия, называется как глагол, например, «отправить заявку», «просмотреть документ» и пр.
- Внешняя сущность – объект за пределами моделируемой системы, который является отправителем или получателем данных – человек, внешний сервис, носитель информации, сторонний источник данных и пр. Обозначается квадратом. Поскольку является объектом, называется как существительное, к примеру, «Клиент», «Поставщик», «БД ГИБДД», «Госуслуги» и пр.
- Хранилище данных – источник, приемник или промежуточное хранилище данных внутри моделируемой системы – база данных, таблица, документ, список, файл и пр. Обозначается в виде прямоугольника с незакрытым правым краем, может иметь вертикальную черту слева. Поскольку является объектом, называется как существительное: «Список дел», «1С:Предприятие», «CRM-система», «Файл с данными заказов», «Заявка» и пр.
- Поток данных – непосредственно данные, которые входят в процессы и хранилища или выходят из них. Например, «ФИО клиента», «Номер договора», «Сведения по заявке», «Запрос» и т.д. Обозначаются как сплошные стрелки с подписями.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
23 декабря, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Правил для построения DFD-диаграмм совсем немного, и все они очень простые:
- потоки данных перемещаются между хранилищами через процессы. Рекомендуется также показывать промежуточные хранилища данных при их перемещении между процессами, однако на практике это нее всегда строго соблюдается.
- В отличие от IDEF0, не важно, с какой стороны стрелка входит в блок «процесс» или «хранилище данных», а также с какой стороны выходит. Поток данных, выходящий из процесса, является его выходом (результатом), а входящий – входом.
- Как и в IDEF0, разработка моделей в нотации DFD начинается с контекстной диаграммы, которая представляет собой 1 процессный блок и также может включать 1 или несколько внешних сущностей. Дальнейшая декомпозиция этого «черного ящика» выполняется на следующих уровнях иерархии, т.е. вложенных диаграммах.
- В отличие от процессно-событийных нотаций BPMN, EPC и UML activity, DFD не содержит логических операторов (XOR, AND OR).
Чтобы показать реализацию этих правил на наглядном примере, далее рассмотрим уже упоминавшийся кейс нашей системы генерации промокодов после прохождения тестов, которые дают возможность оплатить курс со скидкой. Описание этой системы с помощью UML-диаграмм изложено в прошлой статье.
Как построить диаграмму движения потоков данных: практический пример
В конце лета наша Школа прикладного бизнес-анализа запустила маркетинговую акцию для частных клиентов, выдавая промокод на скидку по определенному курсу после прохождения тематического теста на сайте. Таким образом, всю последовательность действий по генерации промокода и его применению можно упрощенно представить следующим образом:
- пользователь проходит тест;
- получает промокод из базы данных промокодов;
- в базе обновляется статус промкода, например, из состояния «новый» он переходит в состояние «выданный»;
- пользователь оставляет свой email на веб-странице с итогами теста, если хочет получить напоминание по электронной почте;
- email пользователя добавляется в базу данных подписчиков;
- для пользователя формируется мааркетинговое предложение в виде электронного письма с указанием промокода, данными о его сроке действия, размеру скидке и курсе, на который он распространяется (даты проведения, стоимость, pdf-файл программы);
- сформированное письмо отправляется пользователю по электронной почте с указанным email-адресом;
- пользователь переходит по ссылке в электронном письме для оплаты курса;
- пользователь оплачивает курс со скидкой по промокоду (этот процесс подробнее рассмотрен в виде UML-диаграммы последовательности здесь);
- после оплаты статус использованного промокода в базе промокодов меняется на «применен».
Таким образом, здесь можно выделить следующие хранилища данных:
- веб-страница с итогами теста;
- база данных с промокодами;
- каталог курсов, где хранятся данные об их названиях, коде, стоимости и датах проведения;
- список подписчиков;
- список рассылок;
- веб-страница оплаты.
Чтобы визуально выделить процессы, которые совершает пользователь, на диаграмме они отмечены голубым цветом. А хранилища данных, которые видны пользователю – желтым. Это не соответствует правилам DFD-нотации, но и не нарушает их: о цветовой маркировке блоков в первоисточниках ничего не сказано. Вообще прием с цветовым выделением некоторых блоков довольно удобен – я часто использую его на практике, чтобы облегчить читателю чтение диаграмм. В итоге для этого примера была составлена следующая DFD-диаграмма, показанная на рисунке ниже (контекстная диаграмма здесь не отображена).
В реализацию пошли не все описанные идеи этого кейса, но основные задумки реализованы. Проверить, как работает выдача промокодов на оплату наших курсов по бизнес-анализу со скидкой мы можете, выполнив любой открытый тест на нашем сайте бесплатно и без регистрации. А научиться самостоятельно разрабатывать DFD-диаграммы и освоить другие нотации моделирования бизнес-процессов вам помогут мои авторские курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Методы описания бизнес-процессов (IDEF, BPMN, EPC, UML)
- Основы бизнес-анализа: вход в профессию для начинающих
