Диаграммы потоков данных · Конспекты по бизнес-анализу

Что это#

Руководство BABOK® называет четыре элемента диаграммы потоков данных (data flow diagram, DFD):

Внешняя сущность (external entity) — человек, организация или система за границами системы, которая отправляет или получает данные (источник или приёмник).
Процесс — действие, которое преобразует входящие данные в исходящие.
Хранилище данных (data store) — данные в покое: файл, таблица или реестр, из которых процессы читают и в которые записывают.
Поток данных — данные в движении между тремя другими элементами; изображается подписанной стрелкой.

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

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

Когда применять#

Применяйте DFD, когда нужно:

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

Руководство BABOK относит технику к задачам «Поддержание требований» (поиск похожих структур данных для повторного использования) и «Спецификация и моделирование требований».

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

Как это делать#

Нарисуйте контекстную диаграмму. Один процесс на всю систему; добавьте все внешние сущности и все входящие и исходящие потоки. Проверьте её с заинтересованными сторонами, прежде чем идти глубже.
Называйте элементы единообразно. Процессы называют глаголом и существительным («Зарегистрировать бронирование»), потоки и хранилища — существительными («запрос на бронирование», «Бронирования»).
Раскройте уровень 1. Разбейте систему примерно на пять—девять процессов, добавьте хранилища данных и соедините всё потоками.
Соблюдайте правила соединения. Данные движутся только через процессы: никогда напрямую между двумя внешними сущностями, двумя хранилищами или хранилищем и внешней сущностью.
Проверьте каждый процесс. У каждого процесса должен быть хотя бы один вход и один выход. Процесс со входами, но без выходов (или с выходами, но без входов) сигнализирует о пропущенном потоке.
Сбалансируйте уровни. Потоки, которые входят в родительский процесс и выходят из него, должны совпадать с потоками на его дочерней диаграмме.
Остановитесь и напишите мини-спецификации, когда процесс можно описать коротким абзацем или таблицей решений.
Свяжите потоки со словарём данных, чтобы содержимое каждого потока было определено.

Пример#

«Мастерская» (вымышленная сеть веломастерских) хочет онлайн-запись, уведомления о статусе и более удобный заказ запчастей.

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

Внешняя сущность
Система как единый процесс (0)

Рис. 1. Контекстная диаграмма. Вся система — один процесс; каждый поток данных пересекает её границу. Нотация: диаграмма потоков данных, нотация Йордона — Де Марко

Показать текстом

Клиент               --запрос на бронирование-->   [0 Система бронирования и ремонта]
[Система]            --подтверждение брони-->      Клиент
[Система]            --уведомление о статусе-->    Клиент
Механик              --ход ремонта-->              [Система]
Механик              --потребность в запчастях-->  [Система]
[Система]            --список работ-->             Механик
[Система]            --заказ запчастей-->          Поставщик запчастей
Поставщик запчастей  --накладная-->                [Система]
[Система]            --расписание на день-->       Управляющий мастерской

Уровень 1:

Внешняя сущность
Процесс
Хранилище данных

Рис. 2. Диаграмма уровня 1. Система разбита на пять процессов и три хранилища данных; потоки к внешним сущностям и от них совпадают с контекстной диаграммой. Нотация: диаграмма потоков данных, нотация Йордона — Де Марко

Показать текстом

1 Зарегистрировать бронирование : запрос на бронирование -> D1 Бронирования; подтверждение брони -> Клиент
2 Спланировать загрузку         : D1 Бронирования -> список работ -> Механик; расписание на день -> Управляющий мастерской;
                                  новый ремонтный заказ -> D2 Ремонтные заказы
3 Зафиксировать ход ремонта     : ход ремонта (Механик) -> D2 Ремонтные заказы
4 Уведомить клиента             : смена статуса из D2 Ремонтные заказы -> уведомление о статусе -> Клиент
5 Заказать запчасти             : потребность в запчастях (Механик) + D3 Склад запчастей -> заказ запчастей -> Поставщик запчастей;
                                  накладная -> D3 Склад запчастей

Каждый поток контекстной диаграммы снова появляется на уровне 1, поэтому уровни сбалансированы. При построении процесса 5 всплыл вопрос, который никто раньше не задавал: кто подтверждает заказ запчастей, прежде чем он уйдёт поставщику? Этот вопрос вынесли на следующий семинар.

Мини-спецификация процесса 4 (вымышленная): «Когда статус ремонтного заказа меняется на Готов к выдаче, отправить одно сообщение по выбранному клиентом каналу связи, указав адрес мастерской и часы работы».

Частые ошибки#

Рисуют блок-схему с решениями и циклами → DFD показывает только движение данных; последовательность отражайте в модели процесса.
Потоки идут напрямую между хранилищами или сущностями → проводите их через процесс, который что-то делает с данными.
Несбалансированные уровни → сверяйте каждую дочернюю диаграмму со входами и выходами родительского процесса.
Расплывчатые подписи вроде «данные» или «информация» → называйте фактическое содержимое и определяйте его в словаре данных.
Слишком много на одной диаграмме → раскройте часть на нижнем уровне.
Смешение нотаций → выберите для всего набора диаграмм нотацию либо Йордона, либо Гейна — Сарсона.

Чек-лист#

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

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

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.13 «Диаграммы потоков данных».
Watermark Learning. BABOK v3 Study Tables. 2016 (учебное пособие к Руководству BABOK). Техника 10.13.
Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 5 (нотации, декомпозиция, мини-спецификации, контекстная диаграмма).