Диаграмма потока данных
Диаграмма потока данных — это способ представления потока данных через процесс или систему (обычно информационную систему ). 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]
См. также [ править ]
- Диаграмма деятельности
- Модель бизнес-процесса и обозначения
- Диаграмма потока управления
- Остров данных
- Поток данных
- Визуализация данных и информации
- Ориентированный ациклический граф
- Drakon-chart
- Функциональная блок-схема
- Функциональная модель
- IDEF0
- Трубопровод
- Методика структурного анализа и проектирования
- Структурная диаграмма
- Контекстная диаграмма системы
- Картирование потока создания ценности
- Рабочий процесс
- Список графических методов
Ссылки [ править ]
- ↑ Перейти обратно: Перейти обратно: а б Брюза, ПД; ван дер Вейде, Т. П. (01.11.1990). «Оценка качества просмотра гипертекста». Форум ACM SIGIR . 24 (3): 6–25. дои : 10.1145/101306.101307 . ISSN 0163-5840 . S2CID 8507530 .
- ^ Мартин, Дэвид; Эстрин, Джеральд (1 апреля 1967 г.). «Модели вычислений и систем — оценка вершинных вероятностей в графовых моделях вычислений» . Журнал АКМ . 14 (2): 281–299. дои : 10.1145/321386.321391 . ISSN 0004-5411 .
- ↑ Перейти обратно: Перейти обратно: а б с Юрдон, Эдвард; Константин, Ларри Л. (1975). Структурированный дизайн . Нью-Йорк: Yourdon Inc., стр. 54–55. OCLC 1036882595 .
{{cite book}}
: CS1 maint: дата и год ( ссылка ) - ^ Бергланд, Германия (19 июня 1978 г.). «Методологии структурированного проектирования» . Материалы 15-й конференции по автоматизации проектирования . ЦАП '78. Лас-Вегас, Невада, США: IEEE Press: 475–493. дои : 10.1109/DAC.1978.1585214 .
- ↑ Перейти обратно: Перейти обратно: а б ДеМарко, Том (1979). Структурный анализ и спецификация системы . Серия программного обеспечения Prentice-Hall. Энглвуд Клиффс, Нью-Джерси: Прентис-Холл. ISBN 978-0-13-854380-8 .
- ↑ Перейти обратно: Перейти обратно: а б Гейн, Крис; Сарсон, Триш (1979). Структурированный системный анализ: инструменты и методы . Серия программного обеспечения Prentice-Hall. Энглвуд Клиффс, Нью-Джерси: Прентис-Холл. ISBN 978-0-13-854547-5 .
- ↑ Перейти обратно: Перейти обратно: а б с д и ж г час Юрдон, Эдвард (1975). «Структурированное программирование и структурированный дизайн как виды искусства». Материалы национальной компьютерной конференции и выставки 19–22 мая 1975 г. - AFIPS '75 . п. 277. дои : 10.1145/1499949.1499997 . S2CID 36802486 .
- ^ Тангкаваров, IRHT; Ваворунту, Дж. (апрель 2016 г.). «Сравнение методов моделирования бизнес-процессов» . Серия конференций IOP: Материаловедение и инженерия . 128 : 012010. doi : 10.1088/1757-899X/128/1/012010 . ISSN 1757-8981 .
- ^ Ларман, Крейг (2012). Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и итеративную разработку (3-е изд.). Нью-Дели: Пирсон. ISBN 978-8177589795 . OCLC 816555477 .
- ^ Репа, Вацлав (1999). Анализ и проектирование информационных систем (Изд. 1). Прага: Экопресс. ISBN 978-8086119137 . OCLC 43612982 .
Библиография [ править ]
- Скотт В. Эмблер . The Object Primer, 3-е издание. Разработка на основе гибкой модели с использованием UML 2.
- Шмидт Г. Метод и приемы организации. 13-е издание, Гиссен, 2003 г.
- Сталкнехт П. , Хазенкамп У.: Введение в бизнес-информатику. 12-е издание, Берлин, 2012 г.
- Гейн, Крис ; Сарсон, Триш. Структурированный системный анализ: инструменты и методы . Нью-Йорк: Улучшенные системные технологии, 1977. ISBN 978-0930196004 . стр. 373
- Демарко, Том. Структурный анализ и спецификация системы . Нью-Йорк: Yourdon Press, 1979. ISBN 978-0138543808 . С. 352.
- Юрдон, Эдвард . Структурное проектирование: основы дисциплины проектирования компьютерных программ и систем . Нью-Йорк: Yourdon Press, 1979. ISBN 978-0138544713 . С. 473.
- Пейдж-Джонс, Мейлир . Практическое руководство по проектированию структурированных систем . Нью-Йорк: Yourdon Press, 1988. ISBN 978-8120314825 . С. 384.
- Юрдон, Эдвард . Современный структурный анализ . Нью-Йорк: Yourdon Press, 1988. ISBN 978-0135986240 . С. 688.
Внешние ссылки [ править ]
- СМИ, связанные со схемой потока данных , на Викискладе?