Visual Paradigm Desktop | 
Visual Paradigm Online
Диаграммы потоков данных (DFD) служат визуальным чертежом информационных систем. В отличие от кода, который описывает логику через синтаксис, DFD описывает логику через движение. Она отображает, как данные поступают в систему, трансформируются через различные процессы и выходят в виде выходных данных или хранения. Данное руководство предоставляет всесторонний обзор по созданию этих диаграмм без использования проприетарных инструментов, делая акцент на основополагающих принципах системного анализа.
Независимо от того, определяете ли вы требования для новой приложения или проводите аудит существующей устаревшей системы, понимание потока данных имеет критическое значение. Хорошо структурированная DFD устраняет неоднозначность. Она заставляет заинтересованные стороны согласиться с тем, откуда берется информация и где она заканчивается. В этом документе рассматриваются анатомия DFD, правила, регулирующие их построение, а также методологии декомпозиции сложных систем на управляемые представления.
Диаграмма потоков данных — это не диаграмма управления. Она не показывает время или последовательность событий. Вместо этого она фокусируется на самих данных. Представьте её как карту речной системы. Вам не важно, насколько быстро течёт вода или какая погода, важно, где находятся притоки, водохранилища и устья рек.
При моделировании бизнес-системы DFD отвечает на три основных вопроса:
Отвечая на эти вопросы, вы создаете логическое представление бизнеса. Это представление остается актуальным независимо от используемой технологической стека для построения системы. Это язык абстракции, который мостит разрыв между бизнес-потребностями и технической реализацией.
Каждая диаграмма потоков данных строится с использованием четырех конкретных символов. Хотя нотации немного различаются между методологиями, лежащие в основе концепции остаются неизменными. Овладение этими элементами — основа точного моделирования.
Внешние сущности представляют источники или пункты назначения данных, которые находятся за пределами моделируемой системы. Это часто люди, отделы или другие системы, взаимодействующие с основной системой.
На диаграммах они обычно изображаются в виде квадратов или прямоугольников. Они всегда должны быть подключены к процессу; данные не могут просто появиться из ниоткуда или исчезнуть в никуда.
Процесс преобразует входные данные в выходные данные. Это движущая сила системы. На DFD процессы обычно изображаются в виде кругов или закругленных прямоугольников. Имя процесса всегда должно быть фразой глагол-существительное, чтобы указать на действие.
Каждый процесс должен иметь хотя бы один вход и один выход. Если процесс имеет входы, но нет выходов, это «черная дыра». Если процесс имеет выходы, но нет входов, это «чудо». Оба случая представляют собой ошибки моделирования.
Хранилища данных представляют собой места, где информация сохраняется для последующего извлечения. Это может быть база данных, файловая система, физический файловый шкаф или временный буфер. В отличие от процессов, хранилища данных не изменяют данные; они только хранят их.
Обычно они изображаются в виде прямоугольников с открытыми концами или двух параллельных линий. Они соединяются с процессами с помощью потоков данных, что указывает на операции чтения или записи.
Потоки данных — это стрелки, соединяющие компоненты. Они представляют перемещение данных между сущностями, процессами и хранилищами. Направление стрелки указывает направление перемещения.
Сложные системы нельзя изобразить на одной странице. Чтобы управлять сложностью, диаграммы потоков данных (DFD) декомпозируются на различные уровни детализации. Такой иерархический подход позволяет аналитикам приближаться и отдаляться от архитектуры системы.
Диаграмма контекста — это самый высокий уровень представления. Она показывает всю систему в виде одного процесса. Иллюстрирует, как система взаимодействует с внешними сущностями.
Уровень 1 расширяет единственный процесс из диаграммы контекста до основных подпроцессов. На этом уровне определяются основные функциональные области системы.
Уровень 2 фокусируется на конкретных процессах уровня 1. Он разбивает сложные функции на более мелкие, выполнимые шаги. На этом уровне часто ищут специфические требования к логике разработчики.
Существует два доминирующих стиля обозначений, используемых в анализе систем. Хотя логика остается одинаковой, визуальное представление различается. Выбор подходящего стиля зависит от знакомства команды и стандартов организации.
| Функция | Yourdon & DeMarco | Gane & Sarson |
|---|---|---|
| Форма процесса | Скруглённый прямоугольник | Скруглённый прямоугольник |
| Форма сущности | Квадрат | Квадрат |
| Форма хранилища данных | Открытый прямоугольник | Открытый прямоугольник с более толстой верхней/нижней частью |
| Форма потока данных | Изогнутая стрелка | Прямая стрелка |
| Позиция метки потока | Под линией | Сверху или снизу |
Выбор между Gane & Sarson и Yourdon & DeMarco в основном косметический. Однако важна последовательность. Смешивание обозначений в одном документе вызывает путаницу и снижает читаемость документации.
Построение диаграммы потока данных — это систематический процесс. Он требует итераций и проверки. Следуйте этим шагам, чтобы обеспечить точность и полноту.
Прежде чем рисовать одну линию, определите, что находится внутри системы, а что снаружи. Это часто определяется масштабом проекта. Все, что поставляет входные данные или получает выходные данные, является условием границы.
Перечислите все источники и пункты назначения. Проведите интервью с заинтересованными сторонами, чтобы определить, кто взаимодействует с системой. Не забывайте об автоматизированных системах; они являются сущностями, такими же, как и люди.
Начните с общей картины. Нарисуйте систему в виде одного пузыря. Соедините внешние сущности стрелками. Подпишите стрелки данными, которые обмениваются. Это служит опорой для всех последующих диаграмм.
Расширьте один пузырь до уровня 1. Определите основные функции. Разбейте систему на логические части. Убедитесь, что входы и выходы диаграммы уровня 0 совпадают с суммарными входами и выходами процессов уровня 1.
Определите, где должны храниться данные. Если процессу нужно запомнить информацию из предыдущей транзакции, требуется хранилище данных. Подключите эти хранилища к соответствующим процессам.
Это критическое правило. Входы и выходы родительского процесса должны быть равны сумме входов и выходов его дочерних процессов. Если диаграмма контекста показывает «Заказ получен», то диаграмма уровня 1 также должна показывать «Заказ получен», входящий в систему в каком-либо месте.
Пройдитесь по диаграмме. Проделайте путь данных от начала до конца. Данные передаются логично? Есть ли несвязанные процессы? Все ли потоки данных подписаны?
Даже опытные аналитики допускают ошибки при построении этих моделей. Знание распространённых ошибок может значительно сэкономить время на этапе проверки.
Важно различать логический и физический взгляд на систему. Логическая диаграмма потоков данных описываетчто что делает система. Физическая диаграмма потоков данных описываеткак как система это делает.
Начните с логической модели. Не вводите технические ограничения слишком рано. Введение технологии слишком рано может ограничить варианты проектирования и создать предвзятость при анализе. Как только логическая модель будет утверждена, можно вывести физическую модель для руководства разработкой.
Чтобы обеспечить, что диаграммы потоков данных (DFD) оставались полезными на протяжении всего жизненного цикла проекта, соблюдайте эти стандарты.
Зачем тратить время на рисование этих диаграмм? Текстовые требования подвержены неверной интерпретации. Предложение, описывающее процесс, может быть прочитано по-разному. Диаграмма — визуальная и пространственная.
Когда заинтересованное лицо видит диаграмму, оно может сразу заметить отсутствующие потоки. Оно может увидеть, где данные дублируются. Оно может понять сложность системы за мгновение. Такое визуальное подтверждение снижает риск создания неправильной системы.
Более того, диаграммы потоков данных служат инструментом коммуникации между бизнес- и техническими командами. Бизнес-аналитики используют их для понимания требований. Разработчики используют их для понимания архитектуры. Поддерживая общий артефакт, организация уменьшает разобщённость и улучшает согласованность.
Реализация методологии диаграмм потоков данных требует дисциплины. Недостаточно просто нарисовать линии; вы должны понимать правила сохранения данных и декомпозиции. По мере практики вы обнаружите, что диаграммы становятся естественным продолжением вашего мыслительного процесса.
Начните с малого. Моделируйте простую транзакцию. Затем расширьте до отдела. Наконец, моделируйте всю организацию. На каждом уровне ваше понимание системы углубляется. Цель не в создании идеального рисунка, а в создании чёткой карты движения информации, которая направляет построение надёжных программных решений.
Помните, что диаграмма — это инструмент мышления, а не просто документ для хранения. Используйте её для проверки предпосылок, выявления пробелов и проверки логики. В сфере проектирования систем ясность остаётся высшей формой точности.
Соблюдая эти принципы, вы обеспечиваете точную документацию перемещения данных в любой бизнес-системе и понимание всех заинтересованных сторон, участвующих в жизненном цикле проекта.