Схема информационных потоков программы

DFD (data flow diagram) — диаграмма потоков данных, один из основных инструментов структурного анализа и проектирования информационных систем, существовавших еще до широкого распространения UML.

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

Примеры движения данных в жизни

С потоками данных мы сталкиваемся не только при решении IT-задач, но и в реальной повседневной жизни.

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

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

Что такое BPMN 2.0: Базовые элементы нотации

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

Потоки данных. Финансовые транзакции как пример движения данных

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

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

Наиболее актуальный жизненный пример движения данных — это вакцинация от коронавируса. В пункте вакцинации мы предоставляем данные паспорта, медицинского полиса и СНИЛС. Медицинский работник вписывает в рабочий журнал представленные нами сведения, дату прививки и данные о вакцине. Затем сведения вносятся в Регистр вакцинированных от COVID-19. Оттуда данные передаются в Госуслуги, где мы можем скачать личный QR-код.

Вакцинация от COVID-19 как еще один пример движения данных

Курс Анны Вичуговой

«Моделирование бизнес-процессов»

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

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

Кейс #1 Оптимизация затрат на недвижимость

Рисуем схему с нуля. BPMN. Практика в diagrams.net для начинающих

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

Потоки данных. Оптимизация затрат на недвижимость

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

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

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

Кейс #2 Наполнение CRM-системы

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

Потоки данных. Наполнение CRM-системы

Кейс #3 Сквозная аналитика по веб-рекламе

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

Потоки данных. Сквозная аналитика по веб-рекламе

Кейс #4 Анализ конверсии сайта

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

Потоки данных. Анализ конверсии сайта

Зачем нужны DFD-диаграммы?

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

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

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

Три уровня проектирования DFD

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

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

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

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

Структурный анализ

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

Структурный анализ — метод исследования системы, который начинается с её общего обзора, а затем иерархически детализируется по уровням абстракции. Иными словами, структурный анализ предполагает, что мы идем от общего к частному, разбивая систему как «черный ящик» на множество «черных ящиков», последовательно приближаясь к результату.

Иерархическая детализация по уровням абстракции

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

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

• «разделяй и властвуй»
• иерархическая упорядоченность
• решение проблем через их разделение на множество независимых задач — «черных ящиков»

Компоненты DFD-диаграмм

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

Компоненты DFD-диаграмм

Виды DFD-нотаций

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

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

Виды DFD-нотации

Основные правила построения DFD-диаграмм

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

Контекстная диаграмма в нотации Йордана де Марко

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

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

Пример #1 Выдача кредита

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

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

Пример DFD: Выдача кредита. Контекстная диаграмма

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

Пример DFD: Выдача кредита

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

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

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

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

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

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

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

Источник: systems.education

Зачем вам DFD-диаграммы или как описать движение потоков данных в бизнес-процессах

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

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

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

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

Итак, DFD-диаграмма включает следующие компоненты:

• Процесс – функция или действия по обработке данных. Обозначается в виде круга или прямоугольника со скругленными краями и горизонтальной чертой внутри. Поскольку используется для описания действия, называется как глагол, например, «отправить заявку», «просмотреть документ» и пр.
• Внешняя сущность – объект за пределами моделируемой системы, который является отправителем или получателем данных – человек, внешний сервис, носитель информации, сторонний источник данных и пр. Обозначается квадратом. Поскольку является объектом, называется как существительное, к примеру, «Клиент», «Поставщик», «БД ГИБДД», «Госуслуги» и пр.
• Хранилище данных – источник, приемник или промежуточное хранилище данных внутри моделируемой системы – база данных, таблица, документ, список, файл и пр. Обозначается в виде прямоугольника с незакрытым правым краем, может иметь вертикальную черту слева. Поскольку является объектом, называется как существительное: «Список дел», «1С:Предприятие», «CRM-система», «Файл с данными заказов», «Заявка» и пр.
• Поток данных – непосредственно данные, которые входят в процессы и хранилища или выходят из них. Например, «ФИО клиента», «Номер договора», «Сведения по заявке», «Запрос» и т.д. Обозначаются как сплошные стрелки с подписями.

Источник: babok-school.ru

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

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

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

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

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

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

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

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

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

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

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

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

1. Внешние сущности — внешние системы, из которых поступает или куда направляется информация в результате взаимодействия с изображаемой системой. Иными словами, это источники и пункты доставки информации, которая приходит или уходит из системы. Такими сущностями могут быть внешние организации, лица, компьютерные или бизнес-системы. Эти сущности также имеют другие названия, например, «терминаторы», «источники», «приемники» или «агенты», и, как правило, располагаются по краям схемы.
2. Процессы — любые процессы, которые ведут к изменению информации и созданию выходных данных. Например, выполнение подсчетов, сортировка данных согласно установленной логике или направление информационного потока в соответствии с бизнес-правилами. Для описания процессов используются краткие метки, например, «Отправка платежа».
3. Хранилища данных — файлы или репозитории, где хранится информация для последующего использования, например, базы данных или формы заявки на участие. Хранилища данных сопровождаются простыми метками, например, «Заказы».
4. Потоки данных — маршруты, по которым информация перемещается между внешними сущностями, процессами и хранилищами данных. Потоки данных иллюстрируют взаимодействие между другими компонентами и отображаются в виде стрелок, как правило, с краткими метками, например, «расчетная информация».

Правила и советы по построению диаграмм 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. Это быстро, легко и совершенно бесплатно.

Источник: www.lucidchart.com