Изучение диаграмм потоков данных на примерах: всестороннее руководство

Диаграммы потоков данных (DFD) являются важными инструментами системного анализа, предоставляя четкий визуальный способ понять, как данные перемещаются через информационную систему. Изучая реальные примеры, вы быстро поймете основные концепции и сможете применить их к своим собственным проектам. Это руководство проведет вас через ключевые концепции DFD с использованием примеров из репозитория Visual Paradigm, объясняя символы, правила и логику, лежащую в основе каждой диаграммы.

Понимание основных компонентов

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

Компонент	Описание	Общепринятая нотация (Yourdon & Coad)	Общепринятая нотация (Gane & Sarson)
Внешний элемент	Лицо, организация или система вне моделируемой системы, которая отправляет или получает данные. Примеры: Клиент, Поставщик, Банк. Часто называется «источником» или «стоком».	Прямоугольник	Прямоугольник
Процесс	Деятельность или функция, преобразующая входящие данные в исходящие. Должен иметь как минимум один вход и один выход. Примеры: «Проверка оплаты», «Отгрузка заказа».	Круг	Округлённый прямоугольник
Хранилище данных	Место, где хранятся данные для последующего использования. Это может быть база данных, файл или даже картотека.	Две параллельные линии	Прямоугольник с открытым концом
Поток данных	Путь, по которому данные перемещаются от одной части системы к другой. Обозначается стрелкой и показывает направление движения.	Стрелка	Стрелка

Примечание:Существует две основные нотации DFD — Yourdon & Coad и Gane & Sarson. Хотя их символы немного различаются, лежащие в основе концепции идентичны. Важно выбрать одну из них и придерживаться её последовательно.

Сила примеров

Примеры, приведённые в статье Visual Paradigm, отлично подходят для обучения, поскольку показывают DFD на разных уровнях детализации. Системы обычно разбиваются на уровни для управления сложностью. Это называетсяуровневой декомпозицией .

• Схема контекста (уровень 0): Это самый высокий уровень представления. Он показывает всю систему как один процесс и её взаимодействие со всеми внешними сущностями. Он даёт простое, общее представление о системе. Хранилища данных на этом уровне НЕ показаны так как они находятся внутри системы.

• Уровень 1 СДП: Эта схема «раскрывает» единственный процесс из схемы контекста на его основные подпроцессы. Она показывает основные функции системы, как данные перемещаются между ними, и впервые вводит хранилища данных. СДП уровня 1 должен «сбалансироваться» с схемой контекста, то есть потоки данных, входящие и выходящие из системы, должны оставаться неизменными.

• СДП уровня 2 (и далее): Эти схемы предоставляют дополнительные детали, разбивая один из процессов схемы уровня 1. Этот процесс продолжается до тех пор, пока не будет достигнут желаемый уровень детализации.

Руководимый пример: система заказа еды

Давайте проанализируем пример «системы заказа еды», упомянутый в статье, чтобы увидеть эти концепции в действии.

1. Схема контекста (уровень 0):

• Внешние сущности: Вероятно, это Покупатель и Кухня. Покупатель предоставляет заказы и получает еду; кухня получает заказы и подтверждает их статус.

• Единственный процесс: Вся система заказа еды представляется как один процесс (например, «Система заказа еды»).

• Потоки данных: «Заказ» (Покупатель → Система), «Еда» (Система → Покупатель), «Запрос на заказ» (Система → Кухня), «Статус заказа» (Кухня → Система). Эта схема даёт вам обзор масштаба системы с высоты 10 000 футов.

2. СДП уровня 1:

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

  

  • 1.0 Обработка заказа: Получает заказ покупателя, проверяет его и передаёт дальше.

  • 2.0 Подготовка еды: Получает запрос на заказ и координирует приготовление еды.

  • 3.0 Управление оплатой: Обрабатывает процесс оплаты.

• Хранилища данных:Хранилище данных, подобноеD1 Заказможет появиться здесь. Потоки данных, такие как «Сведения о заказе», будут перемещаться от процесса 1.0 к хранилищу данных «Заказ», а «Заказ, готовый к выдаче», будет перемещаться от процесса 2.0 обратно к процессу 1.0 для уведомления клиента.

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

Изучение других примеров

В статье представлен ряд примеров диаграмм потоков данных, иллюстрирующих различные системы и нотации:

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

  

• Приложение для супермаркета:Этот пример демонстрирует, как диаграммы потоков данных могут использоваться для моделирования современного мобильного приложения, взаимодействующего с серверными сервисами, такими как управление запасами и обработка платежей.

  

   

Основные правила

При создании и интерпретации диаграмм потоков данных помните об этих основных правилах:

1. Данные не могут перемещаться напрямую:

   • Между двумя внешними сущностями.

   • Между двумя хранилищами данных.

   • Между внешней сущностью и хранилищем данных.
     Данные всегда должны проходить через процесс .

2. Каждый процесс должен иметь хотя бы один входной и один выходной поток данных .

3. Правила именования:

   • Процессы:Используйте сильные глаголы (например, «Обработать платеж», «Отправить заказ»).

   • Внешние сущности, хранилища данных и потоки данных:Используйте существительные (например, «Клиент», «База данных запасов», «Сведения о заказе»).

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

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

Ссылка