WikiDer > Диаграмма потока данных

Data-flow diagram
Схема потока данных с хранением данных, потоками данных, функцией и интерфейсом
Схема потока данных с хранилищем данных, потоками данных, функцией и интерфейсом

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

Есть несколько обозначений для отображения диаграмм потоков данных. Представленные выше обозначения были описаны в 1979 г. Том ДеМарко в рамках структурного анализа.

Для каждого потока данных в процессе должна существовать по крайней мере одна из конечных точек (источник и / или место назначения). Уточненное представление процесса может быть выполнено на другой диаграмме потоков данных, которая подразделяет этот процесс на подпроцессы.

Диаграмма потоков данных является частью инструментов моделирования структурированного анализа. Когда используешь UML, то диаграмма деятельности обычно берет на себя роль диаграммы потока данных. Особая форма плана потока данных - это план потока данных, ориентированный на сайт.

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

История

Обозначение DFD основано на теории графов, первоначально использовавшейся в операционных исследованиях для моделирования рабочего процесса в организациях. DFD возник на основе диаграммы деятельности, использованной в методологии SADT (Структурированный анализ и техника проектирования) в конце 1970-х годов. Популяризаторами DFD являются Эдвард Юрдон, Ларри Константин, Том ДеМарко, Крис Гейн и Триш Сарсон.[2]

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

Компоненты DFD

Диаграмма потока данных - нотация Юрдона / ДеМарко
Схема потока данных - Yourdon/Демарко обозначение

DFD состоит из процессов, потоков, складов и терминаторов. Есть несколько способов просмотреть эти компоненты DFD.[4]

Процесс

Процесс (функция, преобразование) является частью системы, преобразующей входы в выходы. Символ процесса - круг, овал, прямоугольник или прямоугольник со скругленными углами (по типу обозначений). Процесс описывается одним словом, коротким предложением или фразой, которая ясно выражает его суть.[2]

Поток данных

Поток данных (поток, поток данных) показывает передачу информации (иногда также материальной) из одной части системы в другую. Символ потока - стрелка. У потока должно быть имя, определяющее, какая информация (или какой материал) перемещается. Исключениями являются потоки, в которых ясно, какая информация передается через объекты, связанные с этими потоками. Материальные сдвиги моделируются в системах, которые не являются просто информативными. Поток должен передавать только один тип информации (материал). Стрелка показывает направление потока (оно также может быть двунаправленным, если информация к / от объекта логически зависит - например, вопрос и ответ). Потоки связывают процессы, склады и терминаторы.[2]

Склад

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

Терминатор

Терминатор - это внешний объект, который общается с системой и находится вне системы. Это могут быть, например, различные организации (например, банк), группы людей (например, клиенты), органы власти (например, налоговая служба) или отдел (например, отдел кадров) одной и той же организации, которая не принадлежит к модельной системе. Ограничитель может быть другой системой, с которой взаимодействует смоделированная система.[2]

Правила создания DFD

Имена объектов должны быть понятными без дополнительных комментариев. DFD - это система, созданная аналитиками на основе интервью с пользователями системы. Он определен для разработчиков системы, с одной стороны, подрядчика проекта, с другой, поэтому имена объектов должны быть адаптированы для модельной области или пользователей-любителей или профессионалов. Имена сущностей должны быть общими (независимыми, например, отдельные лица, выполняющие деятельность), но должны четко указывать сущность. Процессы должны быть пронумерованы для облегчения отображения и перехода к конкретным процессам. Нумерация случайная, однако необходимо поддерживать согласованность на всех уровнях DFD (см. Иерархию DFD). DFD должен быть понятным, так как максимальное количество процессов в одном DFD рекомендуется от 6 до 9, минимум - 3 процесса в одном DFD.[1][2] Исключением является так называемая контекстная диаграмма, где единственный процесс символизирует модельную систему и все терминаторы, с которыми система взаимодействует.

Согласованность DFD

DFD должен соответствовать другим моделям системы - ERD, STD, Data Dictionary и Process Specification. У каждого процесса должно быть свое имя, входы и выходы. У каждого потока должно быть свое имя (исключение см. «Поток»). Каждое хранилище данных должно иметь поток ввода и вывода. Входные и выходные потоки не обязательно должны отображаться в одном DFD - они должны существовать в другом DFD, описывающем ту же систему. Исключение составляет склад, находящийся вне системы (внешнее хранилище), с которым система взаимодействует.[2]

Иерархия DFD

Чтобы сделать DFD более прозрачным (т.е.не слишком много процессов), можно создать многоуровневые DFD. DFD, которые находятся на более высоком уровне, менее детализированы (более подробные DFD агрегируются на более низких уровнях). Контекстный DFD является самым высоким в иерархии (см. Правила создания DFD). За так называемым нулевым уровнем следует DFD 0, начиная с нумерации процесса (например, процесс 1, процесс 2). На следующем, так называемом первом уровне - DFD 1 - нумерация продолжается. Например. процесс 1 разделен на первые три уровня DFD, которые пронумерованы 1.1, 1.2 и 1.3. Аналогично, процессы на втором уровне (DFD 2) нумеруются, например, 2.1.1, 2.1.2, 2.1.3 и 2.1.4. Количество уровней зависит от размера модельной системы. Процессы DFD 0 могут иметь разное количество уровней декомпозиции. DFD 0 содержит наиболее важные (агрегированные) системные функции. Самый нижний уровень должен включать процессы, позволяющие создать спецификацию процесса (спецификацию процесса) примерно для одной страницы формата А4. Если мини-спецификация должна быть длиннее, целесообразно создать дополнительный уровень для процесса, где он будет разложен на несколько процессов. Для четкого обзора всей иерархии DFD можно создать вертикальную (поперечную) диаграмму. Склад отображается на самом высоком уровне, где он используется впервые, а также на каждом более низком уровне.[2]

Смотрите также

Рекомендации

  1. ^ а б Bruza, P. D .; van der Weide, Th. П. (1990-11-01). «Оценка качества гипертекстовых просмотров». ACM SIGIR Форум. 24 (3): 6–25. Дои:10.1145/101306.101307. ISSN 0163-5840. S2CID 8507530.
  2. ^ а б c d е ж грамм час Йордон, Эдвард (1975). «Структурное программирование и структурированный дизайн как формы искусства». Материалы Национальной компьютерной конференции и выставки 19–22 мая 1975 г. - AFIPS '75: 277. Дои:10.1145/1499949.1499997. S2CID 36802486.
  3. ^ Крейг., Ларман (2012). Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и итеративную разработку (3-е изд.). Нью-Дели: Пирсон. ISBN 978-8177589795. OCLC 816555477.
  4. ^ 1958-, Жепа, Вацлав (1999). Аналитика и информационная система (Выд. 1 изд.). Прага: Экопресс. ISBN 978-8086119137. OCLC 43612982.CS1 maint: числовые имена: список авторов (связь)

Библиография

внешняя ссылка