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. Имя хранилища — это существительное во множественном числе (например, orders) — оно происходит от входных и выходных потоков хранилища. Хранилище не обязательно должно быть просто файлом данных, но также может быть, например, папкой с документами, картотечным шкафом или набором оптических дисков. Поэтому просмотр хранилища в 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 содержит наиболее важные (агрегированные) функции системы. Самый нижний уровень должен включать процессы, которые позволяют создать спецификацию процесса примерно на одну страницу A4. Если мини-спецификация должна быть длиннее, целесообразно создать дополнительный уровень для процесса, где он будет разложен на несколько процессов. Для наглядного обзора всей иерархии DFD можно создать вертикальную (поперечную) диаграмму. Склад отображается на самом высоком уровне, где он впервые используется, а также на каждом более низком уровне. [7]

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

Ссылки

  1. ^ ab Bruza, PD; van der Weide, Th. P. (1990-11-01). «Оценка качества представлений гипертекста». Форум ACM SIGIR . 24 (3): 6–25. doi :10.1145/101306.101307. ISSN  0163-5840. S2CID  8507530.
  2. ^ Мартин, Дэвид; Эстрин, Джеральд (1967-04-01). «Модели вычислений и систем — Оценка вероятностей вершин в графовых моделях вычислений». Журнал ACM . 14 (2): 281–299. doi :10.1145/321386.321391. ISSN  0004-5411.
  3. ^ abc Yourdon, Edward; Constantine, Larry L. (1975). Структурированный дизайн . Нью-Йорк: Yourdon Inc. стр. 54–55. OCLC  1036882595.
  4. ^ Бергланд, Г. Д. (1978-06-19). «Методологии структурного проектирования». 15-я конференция по автоматизации проектирования . Лас-Вегас, Невада, США: IEEE Press. стр. 475–493. doi :10.1109/DAC.1978.1585214.
  5. ^ ab DeMarco, Tom (1979). Структурный анализ и спецификация систем . Серия программного обеспечения Prentice-Hall. Englewood Cliffs, NJ: Prentice-Hall. ISBN 978-0-13-854380-8.
  6. ^ ab Gane, Chris; Sarson, Trish (1979). Структурированный системный анализ: инструменты и методы . Серия программного обеспечения Prentice-Hall. Englewood Cliffs, NJ: Prentice-Hall. ISBN 978-0-13-854547-5.
  7. ^ abcdefgh Йордон, Эдвард (1975). "Структурное программирование и структурное проектирование как формы искусства". Труды 19-22 мая 1975 г., национальной компьютерной конференции и выставки - AFIPS '75 . стр. 277. doi : 10.1145/1499949.1499997 . S2CID  36802486.
  8. ^ Tangkawarow, IRHT; Waworuntu, J (апрель 2016 г.). "Сравнительный анализ методов моделирования бизнес-процессов". Серия конференций IOP: Материаловедение и инженерия . 128 (1): 012010. Bibcode : 2016MS&E..128a2010T. doi : 10.1088/1757-899X/128/1/012010 . ISSN  1757-8981.
  9. ^ Ларман, Крейг (2012). Применение UML и шаблонов: введение в объектно-ориентированный анализ и проектирование и итеративную разработку (3-е изд.). Нью-Дели: Pearson. ISBN 978-8177589795. OCLC  816555477.
  10. ^ Репа, Вацлав (1999). Анализ и новая информационная система (Выход. 1-е изд.). Прага: Экопресс. ISBN 978-8086119137. OCLC  43612982.

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

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