Диаграмма потока данных — подробное руководство

Что такое диаграмма потока данных?

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

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

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

Почему ДФД?

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

Модели позволяют инженерам-программистам, заказчикам и пользователям эффективно работать вместе во время анализа и спецификации требований.

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

Вот преимущества метода DFD:

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

DFD против блок-схемы

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

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

Элементы ДПД

  • Сущности . Сущности являются источником и получателем информационных данных. Сущности представлены
    прямоугольниками и имеют собственные имена.

нотация (внешний объект)

  • Процессы . Действия и действия, выполняемые с данными, представлены круглыми или круглыми прямоугольниками.

обозначение (процесс)

  • Хранение данных . Существует два варианта хранения данных — это может быть представлено как — 1. Это может быть представлено в виде прямоугольника без двух маленьких ребер, 2) или в виде открытого прямоугольника только с одним краем
    . Открытый прямоугольник с отсутствующими ребрами.

нотация (хранилище данных)

  • Поток данных — движение данных представлено острыми стрелками. Движение данных показано как движение от нижней части стрелки в качестве источника к острию стрелки в качестве пункта назначения.

нотация (поток данных)

Пример потока данных — электронный банкинг

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

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

Клиент может получить денежную сумму при снятии средств или внести денежную сумму на депозит; В обоих случаях это приводит к обновлению баланса учетной записи в хранилище данных базы данных учетной записи (хотя эту причинно-следственную связь нельзя явно смоделировать).

Клиент может инициировать процесс перевода средств и должен указать адрес счета и сумму средств. Процесс перевода средств может отправить сумму средств в другой банк через интерфейс другого банка.

ОТРЕДАКТИРУЙТЕ ЭТОТ ПРИМЕР ДИАГРАММЫ ПОТОКА ДАННЫХ

Показанный выше пример DFD включает пять процессов, четыре внешних интерфейса/роли и два хранилища данных. Он не претендует на то, чтобы быть исчерпывающим представлением потоков данных в банковской системе, но он достаточно всеобъемлющ, чтобы дать представление о том, как построить DFD.

Метод нисходящей декомпозиции — многоуровневые DFD

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

Чтобы сделать DFD еще более сложным (т. е. не слишком много процессов), вы можете создать многоуровневый DFDS.

  • Контекстная диаграмма содержит управляющий (агрегированный) системный процесс.
  • DFD более высокого уровня является менее подробным (более подробный DFD разрабатывается на нижнем уровне) и называется процессом декомпозиции сверху вниз.
  • Контекстная диаграмма начинается с номеров процессов (например, процесс 1, процесс 2 и т. д.).
  • Нумерация продолжается на следующем так называемом первом уровне (DFD). Например, процесс 1 на контекстной диаграмме уточняется до трех процессов в DFD первого уровня и имеет номера 1.1, 1.2 и 1.3.
  • Аналогичным образом нумеруются процессы второго уровня, например 2.1.1, 2.1.2, 2.1.3 и 2.1.4. Нумерация процессов в иерархии:
    • (1, 2, 3,…);
    • (1.1, 1.2, 1.3,…, 2.1, 2.2, 2.3,…);
    • (1.1.1, 1.1.2, 1.1.3,…).
  • Количество слоев зависит от размера модельной системы.

При выполнении нисходящей декомпозиции в DFD до DFD более низкого уровня входные и выходные данные должны сохраняться между уровнями DFD. Например, уровень n и n+1 должен иметь одинаковые входы и выходы.

Балансировка DFD

Пример DFD — система заказа еды

Контекстная диаграмма (уровень 0 — DFD)

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

  • Показывает обзор границ системы
  • Благодаря простому обозначению, он не требует технических знаний, чтобы понять
  • Легко рисовать, изменять и дорабатывать из-за ограниченной нотации.

На рисунке ниже показана контекстная диаграмма (схема потока данных верхнего уровня), нарисованная для системы заказа еды.

  • Он содержит процесс (форму), представляющий модель системы, в данном случае «систему заказа еды».
  • Также показаны участники, которые будут взаимодействовать с системой, называемые внешними сущностями.

В этом примере поставщик, кухня, менеджер и клиент — это объекты, которые будут взаимодействовать с системой.

Между процессом и внешними сущностями существуют потоки данных (коннекторы), которые показывают, что между сущностями и системой происходит обмен информацией.

ОТРЕДАКТИРУЙТЕ ЭТОТ ПРИМЕР DFD

Context DFD — это точка входа в модель потока данных. Он содержит один и только один процесс и не показывает никакого хранилища данных.

ДФД уровня 1

DFD уровня 1 представляет более подробное представление системы, чем контекстная диаграмма. Показывая основные подпроцессы и хранилища данных, составляющие систему.

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

ОТРЕДАКТИРУЙТЕ ЭТОТ ПРИМЕР ДИАГРАММЫ ПОТОКА ДАННЫХ

Пример блок-схемы данных системы заказа продуктов питания содержит три процесса, четыре внешних объекта и два хранилища данных.

  1. По диаграмме мы знаем, что покупатель может оформить заказ. Процесс заказа продуктов питания получает заказ, пересылает его на кухню, сохраняет в хранилище данных заказов и сохраняет обновленные сведения об инвентаризации в хранилище данных инвентаризации. Процесс также обеспечивает выставление счетов клиенту.
  2. Менеджеры могут получать отчеты с помощью процесса «Создать отчет», в котором сведения о запасах и заказах используются в качестве входных данных для хранилищ данных запасов и заказов соответственно.
  3. Менеджер также может инициировать процесс инвентаризации заказа, предоставив заказ инвентаризации. Этот процесс пересылает заказ инвентаризации поставщику и сохраняет обновленные данные инвентаризации в хранилище данных инвентаризации.

Логический и физический DFD

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

Логический DFD

  • Логический DFD показывает, как работает бизнес.
  • Процессы представляют бизнес-операции.
  • Хранилища данных представляют собой набор данных независимо от того, как они хранятся.
  • Это то, как бизнес контролирует.

Физический DFD

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

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

Физический и логический DFD: пример 1

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

Физический и логический DFD: пример 2

Логический пример DFD — продуктовый магазин

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

Логический пример DFD — продуктовый магазин

ОТРЕДАКТИРУЙТЕ ЭТОТ ЛОГИЧЕСКИЙ ПРИМЕР DFD

Пример физического DFD — продуктовый магазин

  • Физический DFD показывает, что используется штрих-код — код UPC PRICE, который можно найти на большинстве товаров в продуктовых магазинах.
  • Кроме того, в физическом DFD упоминаются ручные процессы, такие как сканирование, поясняется, что временный файл используется для хранения промежуточного количества элементов.
  • ОПЛАТА может быть произведена НАЛИЧНЫМИ, ЧЕКОМ или ДЕБЕТОВОЙ КАРТОЙ.

Наконец, это относится к квитанции по ее названию, КАССОВАЯ КВИТАНЦИЯ.

ОТРЕДАКТИРУЙТЕ ЭТОТ ФИЗИЧЕСКИЙ ПРИМЕР DFD

Советы и примечания к диаграммам потоков данных

  • Не делайте это слишком сложным; обычно 5-7 человек могут управлять процессами
  • Хранилище данных должно быть связано хотя бы с одним процессом .
  • Поток данных не должен существовать между двумя внешними объектами без прохождения процесса
  • Процесс с входом, но без выхода считается процессом черной дыры.
  • Метки процессов должны быть глагольными фразами; хранилища данных представлены существительными.
  • Внешний объект должен быть связан хотя бы с одним процессом
  • DFD недетерминированы — нумерация не обязательно указывает порядок и полезна для идентификации процессов при обсуждении с пользователями.
  • Хранилище данных не должно быть подключено к внешнему объекту, в противном случае это означает, что вы предоставляете внешнему объекту прямой доступ к вашему файлу данных.

Ресурсы

Leave a Reply

Ваш адрес email не будет опубликован.