Моделирование потоков данных dfd кратко

Обновлено: 02.07.2024

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

Читается за 10 мин.

Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.

Что такое диаграмма DFD?

Символы и способы нотации диаграмм DFD

Самые распространенные системы нотации DFD-схем названы в честь их создателей:

Йордон и Коуд;
Йордон и Де Марко;
Гейн и Сарсон.

Подчиняясь правилам и инструкциям выбранной системы, символы отображают четыре компонента диаграммы DFD:

Правила и советы по построению диаграмм DFD

Каждый процесс должен сопровождаться как минимум одним входным и одним выходным потоком;
В каждое хранилище должен впадать как минимум один поток данных и как минимум один — вытекать;
Данные, хранимые в системе, должны проходить через процесс;
Каждый процесс диаграммы DFD должен вести либо к другому процессу, либо к хранилищу данных.

Уровни и слои DFD-схем: от контекстных схем до псевдокода

С помощью слоев и уровней диаграмму DFD можно дополнять всё большими и большими подробностями, фокусируя внимание на одном конкретном участке. Уровни диаграммы обозначаются цифрами 0, 1 или 2, причем иногда нумерация может продолжаться (3 и так далее). Необходимый уровень детализации зависит от стоящих перед вами целей.

DFD 0-го уровня также называется контекстной схемой. Это простейший способ изображения анализируемых или моделируемых систем и процессов. Такие схемы показывают общую картину и представляют систему в виде единого процесса, наделенного связями с внешними сущностями. Схемы 0-го уровня будут понятны широкой аудитории, включая участников проекта, бизнес-аналитиков и разработчиков;

DFD 1-го уровня дает более детальное представление об элементах контекстной схемы. Разбив обобщенный процесс контекстной схемы на подпроцессы, вы тем самым сможете выделить основные функции системы;

DFD 2-го уровня обеспечивает еще более глубокое погружение в систему. Однако чтобы достаточно подробно описать ее устройство, вам придется включить в схему немного больше текста;

Детализация 3-го, 4-го и более глубоких уровней возможна, но составители схем редко идут дальше 3-го уровня, так как излишняя сложность препятствует эффективному сравнению, моделированию и передаче информации.

Слои позволяют собрать выпадающие уровни непосредственно в DFD-схеме: такой метод сочетает глубокий анализ с ясностью изложения.

При достаточно высокой детализации разработчики и дизайнеры могут применить диаграммы DFD для написания псевдокода, который представляет собой сочетание программного и естественного языка. Задача псевдокода — упростить работу по написанию полноценного кода.

Создание диаграмм быстро и легко с Lucidchart. Начните бесплатную пробную версию сегодня, чтобы начать создавать и сотрудничать.

Примеры применения схем потоков данных

Диаграммы DFD отлично подходят для анализа и моделирования систем в различных областях.

DFD в разработке программного обеспечения. Именно в этой сфере в 70-х годах прошлого века начали широко применяться диаграммы DFD. Всё дело в том, что DFD обеспечивает сфокусированный подход на этапе технической разработки, где очень важно собрать и проанализировать информацию, прежде чем приступить непосредственно к написанию кода.

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

DFD в реорганизации бизнес-процессов. Диаграммы DFD можно применять для моделирования более удобных и эффективных маршрутов перемещения данных в пределах бизнес-процесса. Метод реорганизации бизнес-процессов (BPR) зародился в 90-х годах XX века с целью снизить операционные расходы, а также повысить качество обслуживания клиентов и конкурентоспособность компании на рынке.

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

DFD в структурах систем. Любые процессы и системы можно проанализировать с детализацией по нарастающей. Это поможет оптимизировать их как с технической, так и с других точек зрения.

DFD и UML: в чем отличие?

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

Логические и физические диаграммы DFD

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

Нужна дополнительная информация? Читайте наш подробный анализ различий между логическими и физическими DFD-схемами.

Как создать диаграмму DFD

1. Ввод и вывод информации

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

2. Создание контекстной схемы

После того как вы определились с основными пунктами ввода и вывода информации, дальнейшее построение контекстной схемы не составит труда. Добавьте узел единичного процесса и соедините его с необходимыми внешними сущностями. Этот узел символизирует самый обобщенный процесс, через который проходит информация от ввода до вывода.

3. Расширение контекстной схемы до DFD 1-го уровня

Узел единичного процесса, представленный в вашей контекстной диаграмме, дает довольно скудное представление о системе, поэтому рекомендуем разбить его на подпроцессы. Диаграмма DFD 1-го уровня должна включать несколько узлов процессов, а также основные базы данных и все внешние сущности. Отследите путь информационного потока: откуда поступает информация и что с ней должно случиться до перехода к очередному хранилищу?

4. Углубление диаграммы DFD до 2-го уровня и далее

Если вы хотите создать более подробную схему потока данных, следуйте инструкции из пункта 3. Процессы, входящие в состав диаграммы DFD 1-го уровня, можно точно так же разбить на более подробные подпроцессы. Опять же, не забудьте включить в диаграмму все необходимые хранилища и потоки данных. На этом этапе вы должны получить довольно подробную картину своей системы. Однако если вы решите углубить диаграмму дальше 2-го уровня, просто повторите описанный выше процесс. Когда диаграмма достигнет желаемого уровня детализации, с разбивкой можно закончить.

5. Проверка окончательной схемы

Когда схема будет готова, проверьте ее от начала до конца. Обращайте особое внимание на течение информации: логично ли всё изложено? Все ли хранилища данных на месте? Финальный вариант схемы должен давать четкое представление о том, как устроена ваша система. Поэтому, прежде чем организовать презентацию окончательного варианта схемы, попросите коллег проверить, достаточно ли доходчиво она составлена.

Шаблоны и примеры диаграмм DFD

Пример логической диаграммы DFD

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

Пример физической диаграммы DFD

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

Пример контекстной схемы

Ниже показана контекстная DFD-схема, то есть самый простой и обобщенный обзор целой системы или процесса. Такая схема должна быть понятна широкой аудитории, включая участников проекта и разработчиков.

Составлять диаграммы DFD с Lucidchart легко и быстро. Оформите бесплатную ознакомительную версию уже сегодня и начните создавать DFD вместе с коллегами!

Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.

Кейсы из моих проектов

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

Задача состояла в том, чтобы оптимально разместить определённое количество сотрудников в одном месте и сократить излишнюю арендную плату.

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

Дополнительно от службы управления недвижимостью я брала данные о собственных или арендуемых помещениях компании.

Ещё один пример, с которым сталкивается любой бизнес — это наполнение CRM-системы. Источниками данных могут быть телефонные звонки, заявки из форм обратной связи на сайте компании, письма по электронной почте и даже менеджеров по продажам. Потоки данных сливаются в единое хранилище в виде CRM-системы.

Сквозная аналитика по веб-рекламе. Например, мы запустили рекламу на Google Ads, в Яндекс.Директ и через SEO. Из всех источников собираем данные о просмотрах рекламных объявлений и кликах, а затем передаем все эти данные в единую систему аналитики. Также в систему аналитики передаются сведения из CRM о том, откуда именно пришёл клиент.

Ещё один хороший кейс — анализ конверсии сайта. Я получала заявки из CRM-системы в виде CSV-файлов и данные из Google Adwords в этом же формате. Для проверки гипотезы, как связано количество посещений (DAU-метрика) с заявками в этот день, даже пришлось вручную написать небольшой Python-скрипт. Визуализацию результатов можно сделать в дашборде BI-системы или комплексном инструменте аналитики (например, Google Data Studio).

Аналитики используют BPMN и EPC-нотации для того, чтобы описывать логику выполнения бизнес-процесса. Это отличные инструменты, но они не позволяют структурно показать, из каких источников данные поступают, какими процессами преобразуются и куда направляются.

Обычно такие задачи возникают:

в проектах управления данными (Data Management)
при интеграции информационных систем
в проектах внедрения систем электронного документооборота

Проектирование DFD-диаграмм охватывает 3 уровня абстракции:

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

2. Диаграмма логических потоков данных отражает будущее или текущее состояние, описывая какие преобразования должны происходить независимо от физических ограничений.

3. Диаграмма физических потоков данных моделирует хранилища данных: принтеры, формы, устройства и другие проявления данных.

Подобно IDEF0, DFD-нотация относится к SADT-методологии и поддерживает принципы структурного подхода. Проектирование DFD начинается с контекстной диаграммы, которая декомпозируется по уровням детализации. При этом DFD-нотация рассматривает систему с точки зрения объекта, а не процесса, в отличие от IDEF0.

Результат фиксируется с использованием строгих правил записи в соответствии с алфавитом нотации и правилами использования элементов этого алфавита.

На каждом уровне контекст ограничен и включает в себя только существенные для данного уровня элементы. При этом следует помнить, что оптимальное рекомендуемое число элементов на каждом уровне — от трех до семи объектов.

Алфавит DFD-нотации включает четыре элемента: процесс, внешняя сущность, хранилище данных и поток данных.

Исторически синтаксис DFD-нотации применяется в двух вариантах: Йордона-Де Марко и Гейна-Сарсона.

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

Правил для построения DFD-диаграмм не так уж и много:

Контекстная диаграмма содержит три основных компонента:

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

Рассмотрим в качестве примера выдачу кредита физическому лицу.

Клиент подаёт заявку на кредит.
Банк оценивает платежеспособность и надежность клиента.
С учетом полученных сведений и на основании истории взаимоотношений с клиентом банк принимает решение о выдаче кредита. Решение содержит данные о выдаваемой сумме и процентной ставке.
Банк создаёт кредитный счёт и перечисляет на него деньги.

Самая важная для проектирования информация содержится внутри процессорного блока. Его содержимое раскрывается в декомпозированной DFD-диаграмме.

Что можно увидеть на этой DFD-диаграмме?

Первичная заявка на кредит в виде входящего потока данных попадает в процесс Первичный скоринг. На выходе из процесса скоринговая оценка клиента направляется в хранилище данных Заявка на кредит. Сюда же попадают данные о желаемой сумме займа и сведения о клиенте.

Клиент как внешняя сущность передаёт сведения о своих доходах. Эти данные помещаются в промежуточное хранилище Справка о доходах.

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

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

Процесс Генерация кредитного договора получает данные о положительном решении службы безопасности, параметры кредита из кредитного договора и данные заемщика. На выходе из процесса одобренная сумма кредита поступает в хранилище данных Кредитный счёт.

Из Кредитного счёта в процесс Выдача денег поступает поток денежных средств. Результатом финального процесса является выдача кредита клиенту.

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

Что такое DFD-нотация и зачем она нужна

Хотя BPMN и EPC нотации позволяют отлично описать логику выполнения бизнес-процессов, о чем мы писали здесь и здесь, иногда требуется показать эту деятельность не с позиции совершаемых действий, а с точки зрения обрабатываемых данных. Иначе говоря, нужно ответить на вопросы, из каких источников данных приходят, как преобразуются и куда отправляются. Обычно такая задача возникает в проектах, связанных с управлением данными (Data Management) и интеграции информационных систем. Методы и способы интеграции ИС мы рассмотрим в другой раз, а пока сфокусируемся на описании движения потоков данных. Именно для этого и нужны DFD-диаграммы (Data Flow Diagram).

Подобно IDEF0, DFD-нотация относится к SADT-методологии и соответствует структурному подходу, поддерживая принципы декомпозиции, иерархической упорядоченности и смыслового разделения сущностей. Хотя DFD и не содержит логических операторов (XOR, AND, OR), которые мы разбирали здесь, а также имеет очень ограниченное число элементов, она отлично позволяет описать последовательность возникновения, изменения и преобразования данных через их движение между процессами и хранилищами. Существует 2 разновидности DFD-диаграмм (Гейна-Сарсона и Йордана-Де Марко), которые немного отличаются лишь обозначениями некоторых элементов.

Стандарт описания бизнес-процессов DFD — Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных.

Использование и особенности DFD диаграмм

Созданные модели потоков Данных организации могут быть использованы при решении таких задач, как:

определение существующих хранилищ данных (текстовые документы, файлы, Система управления базой данных — СУБД);
определение и анализ данных, необходимых для выполнения каждой функции процесса;
подготовка к созданию модели структуры данных организации, так называемая ERD-модель (IDEF1X);
выделение основных и вспомогательных бизнес-процессов организации.

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

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

Графический язык моделирования DFD диаграмм

Существуют две нотации DFD:

Требования к оформлению функций:

Каждая функция должна иметь идентификатор;
Названия работы нужно формулировать согласно следующее формуле:

Название работы = Действие + Объект, над которым действие осуществляется

Требования к оформлению потока данных:

1. Название потока нужно формулировать согласно следующей формуле:

Название потока = Объект, представляющий поток + Статус объекта

[note]Если речь идет о продукции, которую отгрузили клиенту, то поток можно назвать или . В данном случае это объект, представляющий поток, а — статус объекта.[/note]

2. Название должно быть по возможности кратким и состоять из 2-3 слов.

Построение DFD-модели

Построение DFD-модели базируется на принципе декомпозиции. DFD-модель включает в себя три документа, которые ссылаются друг на друга: Графические диаграммы, Миниспецификация, Словарь данных.

1. Контекстная диаграмма или иерархия контекстных диаграмм

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

Однако в некоторых случаях целесообразнее и нагляднее построить несколько контекстных диаграмм с иерархией:

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

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

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

2. Детализация контекстной диаграммы

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

При детализации должны выполняться следующие правила:

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

3. Миниспецификация

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

Миниспецификация является конечной вершиной иерархии модели DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

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

4. Словарь данных

В словаре данных определяется структура и содержание всех потоков данных и накопителей данных, которые присутствуют на диаграммах.

Для каждого потока в словаре хранятся: имя потока, тип, атрибуты.

Простой / групповой (объединяющий несколько потоков)
Внутренний/ внешний;
Поток данных/ поток управления;
Непрерывный (принимающий любые значения в рамках диапазона)/дискретный (принимающий конкретные значения)

Имена-синонимы потока;
В случае группового потока, все потоки которые поток объединяет;
Единицы измерения потока;
Диапазон значения и типичное значение с информацией по обработке экстремальных ситуаций;
Список значений и их смысл для дискретного потока;
Список номеров диаграмм, в которых поток встречается;
Список потоков, в которые поток входит (если в свою очередь входит в другой групповой поток);
комментарии.

Проверка DFD модели

После построения законченной модели системы ее необходимо проверить на полноту и согласованность.

Модель считается полной, если все ее объекты (подсистемы, процессы, потоки данных) подробно описаны и детализированы.

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

Читайте также: