Что такое диаграмма DFD и как ее создать?

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

Самые распространенные системы нотации DFD-схем названы в честь их создателей:

• Йордон и Коуд;
• Йордон и Де Марко;
• Гейн и Сарсон.

Основное различие между этими системами заключается в том, что методы Йордона-Коуда и Йордона-Де Марко для обозначения процессов применяют круги, а метод Гейна-Сарсона — прямоугольные блоки со скругленными углами (которые иногда называют «конфетками»). Безусловно, у этих методов имеются и другие различия. Главное — четко придерживаться выбранной системы нотации при работе с другими участниками проекта.

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

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

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

2. Процессы

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

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

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

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

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

• Каждый процесс должен сопровождаться как минимум одним входным и одним выходным потоком;
• В каждое хранилище должен впадать как минимум один поток данных и как минимум один — вытекать;
• Данные, хранимые в системе, должны проходить через процесс;
• Каждый процесс диаграммы DFD должен вести либо к другому процессу, либо к хранилищу данных.

С помощью слоев и уровней диаграмму DFD можно дополнять всё большими и большими подробностями, фокусируя внимание на одном конкретном участке. Уровни диаграммы обозначаются цифрами 0, 1 или 2, причем иногда нумерация может продолжаться (3 и так далее). Необходимый уровень детализации зависит от стоящих перед вами целей.

• DFD 0-го уровня также называется контекстной схемой. Это простейший способ изображения анализируемых или моделируемых систем и процессов. Такие схемы показывают общую картину и представляют систему в виде единого процесса, наделенного связями с внешними сущностями. Схемы 0-го уровня будут понятны широкой аудитории, включая участников проекта, бизнес-аналитиков и разработчиков;

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

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

​

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

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

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

Диаграммы DFD отлично подходят для анализа и моделирования систем в различных областях.

DFD в разработке программного обеспечения.

DFD в бизнес-аналитике.

DFD в реорганизации бизнес-процессов.

DFD в гибкой разработке.

DFD в структурах систем.

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

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

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

1. Ввод и вывод информации

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

2. Создание контекстной схемы

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

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

3. Расширение контекстной схемы до DFD 1-го уровня

Узел единичного процесса, представленный в вашей контекстной диаграмме, дает довольно скудное представление о системе, поэтому рекомендуем разбить его на подпроцессы. Диаграмма DFD 1-го уровня должна включать несколько узлов процессов, а также основные базы данных и все внешние сущности. Отследите путь информационного потока: откуда поступает информация и что с ней должно случиться до перехода к очередному хранилищу?

4. Углубление диаграммы DFD до 2-го уровня и далее

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

5. Проверка окончательной схемы

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

Пример логической диаграммы DFD

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

Пример физической диаграммы DFD

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

Пример контекстной схемы

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