stringtranslate.com

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

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

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

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

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

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

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

История

Обозначение DFD основано на теории графов , первоначально использовавшейся в операционных исследованиях для моделирования рабочих процессов в организациях и в информатике для моделирования потока входных и выходных данных в ходе вычислений. [2] [3] DFD возник на основе методологии структурного анализа и проектирования в середине 1970-х годов. [3] Впервые он был предложен Ларри Константином, [4] и популяризирован Эдвардом Юрдоном, Томом ДеМарко, [5] Крисом Гейном и Триш Сарсон, [6] [7] , которые обогатили технику построения диаграмм различными обозначениями, практиками словаря данных. [5] и руководство по иерархической декомпозиции процессов. [6]

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

Компоненты DFD

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

DFD состоит из процессов, потоков, складов и терминаторов. Существует несколько способов просмотра этих компонентов DFD. [10]

Процесс

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

Поток данных

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

Склад

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

Терминатор

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

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

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

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

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

Иерархия 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 можно создать вертикальную (поперечную) диаграмму. Склад отображается на самом высоком уровне, где он впервые используется, а также на каждом более низком уровне. [7]

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

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

  1. ^ аб Брузы, PD; ван дер Вейде, Т. П. (01.11.1990). «Оценка качества просмотра гипертекста». Форум ACM SIGIR . 24 (3): 6–25. дои : 10.1145/101306.101307. ISSN  0163-5840. S2CID  8507530.
  2. ^ Мартин, Дэвид; Эстрин, Джеральд (1 апреля 1967 г.). «Модели вычислений и систем - оценка вероятностей вершин в графовых моделях вычислений». Журнал АКМ . 14 (2): 281–299. дои : 10.1145/321386.321391. ISSN  0004-5411.
  3. ^ abc Юрдон, Эдвард; Константин, Ларри Л. (1975). Структурированный дизайн . Нью-Йорк: Yourdon Inc., стр. 54–55. ОКЛК  1036882595.{{cite book}}: CS1 maint: дата и год ( ссылка )
  4. ^ Бергланд, Германия (19 июня 1978 г.). «Методологии структурированного проектирования». Материалы 15-й конференции по автоматизации проектирования . ЦАП '78. Лас-Вегас, Невада, США: IEEE Press: 475–493. дои : 10.1109/DAC.1978.1585214.
  5. ^ аб ДеМарко, Том (1979). Структурный анализ и спецификация системы . Серия программного обеспечения Prentice-Hall. Энглвуд Клиффс, Нью-Джерси: Прентис-Холл. ISBN 978-0-13-854380-8.
  6. ^ аб Гейн, Крис; Сарсон, Триш (1979). Структурированный системный анализ: инструменты и методы . Серия программного обеспечения Prentice-Hall. Энглвуд Клиффс, Нью-Джерси: Прентис-Холл. ISBN 978-0-13-854547-5.
  7. ^ abcdefgh Юрдон, Эдвард (1975). «Структурированное программирование и структурированный дизайн как виды искусства». Материалы национальной компьютерной конференции и выставки AFIPS '75, состоявшейся 19–22 мая 1975 г. п. 277. дои : 10.1145/1499949.1499997 . S2CID  36802486.
  8. ^ Тангкаваров, IRHT; Ваворунту, Дж. (апрель 2016 г.). «Сравнение методов моделирования бизнес-процессов». Серия конференций IOP: Материаловедение и инженерия . 128 : 012010. doi : 10.1088/1757-899X/128/1/012010 . ISSN  1757-8981.
  9. ^ Ларман, Крейг (2012). Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и итеративную разработку (3-е изд.). Нью-Дели: Пирсон. ISBN 978-8177589795. ОКЛК  816555477.
  10. ^ Репа, Вацлав (1999). Анализ и новая информационная система (Выход. 1-е изд.). Прага: Экопресс. ISBN 978-8086119137. ОСЛК  43612982.

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

Внешние ссылки