429.48K
Категория: БизнесБизнес

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

1.

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

2.

DFD
• Диаграммы потоков данных (Data Flow Diagrams — DFD)
представляют собой иерархию функциональных процессов,
связанных потоками данных.
• Цель:
продемонстрировать, как каждый процесс преобразует свои
входные данные в выходные, а также выявить отношения между
этими процессами.

3.

DFD
• Основными компонентами диаграмм потоков данных являются:
внешние сущности;
системы и подсистемы;
процессы;
накопители данных;
потоки данных.

4.

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

5.

Компоненты
• Подсистема (или система) на контекстной диаграмме изображается так, как
она представлена на рисунке:
• Номер подсистемы служит для ее идентификации.

6.

Компоненты
• Процесс представляет собой преобразование входных потоков
данных в выходные в соответствии с определенным алгоритмом.
Физически процесс может быть реализован различными
способами: это может быть подразделение организации (отдел),
выполняющее обработку входных документов и выпуск отчетов,
программа, аппаратно реализованное логическое устройство и
т.д.

7.

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

8.

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

9.

Метод Гейна-Сэрсона
• Для построения DFD традиционно используются две различные нотации,
соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона.
• Эти нотации незначительно отличаются д руг от друга графическим
изображением символов (далее в примерах используется нотация ГейнаСэрсона).
• В соответствии с данным методом модель системы определяется как
иерархия диаграмм потоков данных, описывающих асинхронный процесс
преобразования информации от ее ввода в систему до выдачи потребителю.
Источники информации (внешние сущности) порождают информационные
потоки (потоки данных), переносящие информацию к подсистемам или
процессам.

10.

Метод Гейна-Сэрсона
• Те, в свою очередь, преобразуют информацию и порождают новые потоки,
которые переносят информацию к другим процессам или подсистемам,
накопителям данных или внешним сущностям — потребителям
информации.
• Диаграммы верхних уровней иерархии (контекстные диаграммы)
определяют основные процессы или подсистемы с внешними входами и
выходами. Они детализируются при помощи диаграмм нижнего уровня.
Такая декомпозиция продолжается, создавая многоуровневую иерархию
диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на
котором детализировать процессы далее не имеет смысла.

11.

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

12.

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

13.

Спецификация DFD
• Решение о завершении детализации процесса и использовании
спецификации принимается аналитиком исходя из следующих критериев:
наличия у процесса относительно небольшого количества входных и
выходных потоков данных (2-3 потока);
возможности описания преобразования данных процессов в виде
последовательного алгоритма;
выполнения процессом единственной логической функции преобразования
входной информации в выходную;
возможности описания логики процесса при помощи спецификации
небольшого объема (не более 20-30 строк).

14.

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

15.

Детализация DFD
• При построении иерархии DFD переходить к детализации процессов следует только после
определения содержания всех потоков и накопителей данных, которое описывается при
помощи структур данных. Для каждого потока данных формируется список всех его
элементов данных, затем элементы данных объединяются в структуры данных,
соответствующие более крупным объектам данных (например, строкам документов или
объектам предметной области).
• После построения законченной модели системы ее необходимо верифицировать
(проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы,
процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные
недетализированные объекты следует детализировать, вернувшись на предыдущие шаги
разработки.
• При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для
построения моделей "AS-IS" и "AS-TO-BE", отражая, таким образом, существующую и
предлагаемую структуру бизнес-процессов организации и взаимодействие между ними.
При этом описание используемых в организации данных на концептуальном уровне,
независимом от средств реализации базы данных, выполняется с помощью модели
"сущность-связь".

16.

Пример построения бизнес - моделей с использованием методики Йордона

17.

Метод описания процессов IDEF3
• IDEF3 (Integration Definition for Function Modeling) — это метод,
имеющий основной целью дать возможность аналитикам описать
ситуацию, когда процессы выполняются в определенной
последовательности, а также описать объекты, участвующие
совместно в одном процессе.
• IDEF3 – способ описания процессов с использованием
структурированного метода, позволяющего эксперту в
предметной области представить положение вещей как
упорядоченную последовательность событий с одновременным
описанием объектов, имеющих непосредственное отношение к
процессу.

18.

Метод описания процессов IDEF3
• В отличие от большинства технологий моделирования бизнес-процессов,
IDEF3 не имеет жестких синтаксических или семантических ограничений,
делающих неудобным описание неполных или нецелостных систем.
• IDEF3 также может быть использован как метод проектирования бизнеспроцессов. IDEF3-моделирование органично дополняет традиционное
моделирование с использованием стандарта методологии IDEF0.
• Основой модели IDEF3 служит так называемый сценарий бизнес-процесса,
который выделяет последовательность действий или подпроцессов
анализируемой системы.

19.

Метод описания процессов IDEF3
• Стандарт IDEF3 предназначен для описания бизнес-процессов нижнего
уровня и содержит объекты – логические операторы, с помощью которых
показывают альтернативы и места принятия решений и в бизнес-процессе, а
также объекты – стрелки с помощью которых показывают временную
последовательность работ в бизнес-процессе

20.

Типы связей между работами в стандарте
IDEF3

21.

Перекрестки
• Перекрестками также делятся на несколько типов:
«Исключающий ИЛИ», «И» и «ИЛИ». Перекрестки используются
для отображения логики взаимодействия стрелок (потоков) при
слиянии и разветвлении или для отображения множества
событий, которые могут или должны быть завершены перед
началом следующей работы. Различают перекрестки для слияния
(Fan-in Junction) и разветвления (Fan-out Junction) стрелок.
Перекресток не может использоваться одновременно для
слияния и для разветвления.

22.

Перекрестки
• Перекресток «Исключающий ИЛИ» обозначает, что после
завершения работы «A» (Рисунок 13), начинает выполняться
только одна из трех расположенных параллельно работ B, С или D
в зависимости от условий 1, 2 и 3.
• Перекресток «И» обозначает, что после завершения работы «A»,
начинают выполняться одновременно три параллельно
расположенные работы B, С и D.
• Перекресток «ИЛИ» обозначает, что после завершения работы
«A», может запуститься любая комбинация трех параллельно
расположенных работ B, С и D.

23.

Применение перекрестков «Исключающий ИЛИ»
«И» «ИЛИ» - схема расхождения

24.

Синхронные и асинхронные перекрестки
• Перекрестки «И» и «ИЛИ» подразделяются еще на два подтипа –
синхронные и асинхронные. Перекрестки синхронного типа
обозначают, что работы В, С и D запускаются одновременно после
завершения работы A. Перекрестки асинхронного типа
требований к одновременности не предъявляют.

25.

Применение перекрестков «Исключающий ИЛИ»
«И» «ИЛИ» - схема схождения

26.

Обозначения, названия
и смысл типов
перекрестков в схемах
схождения и расхождения

27.

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

28.

Процесс декомпозиции диаграмм IDEF3
• Перед проведением сеанса экспертизы у экспертов предметной
области должны быть документированные сценарии и рамки модели, для
того чтобы понять цели декомпозиции. Обычно эксперт предметной
области передает аналитику текстовое описание сценария.
• В дополнение к этому может существовать документация, описывающая
интересующие процессы. Из этой информации аналитик должен составить
предварительный список работ (отглагольные существительные,
обозначающие процесс ) и объектов (существительные, обозначающие
результат выполнения работы), которые необходимы для
перечисленных работ.
• В некоторых случаях целесообразно создать графическую модель для
представления ее эксперту предметной области.

29.

Описание
процесса
"Сборка
настольных
компьютеров"
в методологии
IDEF3

30.

Спасибо за внимание
English     Русский Правила