Что описывает dfd перечислите основные компоненты диаграммы
Что такое DFD (диаграммы потоков данных)
В комментариях к одной из моих прошлых статей, посвященной IDEF0, один из пользователей высказал просьбу рассказать подробнее о том, что такое DFD. Понятие это несколько запутанное, многие мои клиенты также задают вопросы о потоках данных и стандартах построения диаграмм. А потому я решил эту статью посвятить DFD.
DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Википедия
По моему мнению, определение из русскоязычной Википедии, несколько перегружено информацией и, в результате, излишне сложно для понимания. Кроме того, лично я считаю, что DFD и UML — это разные инструменты, а потому некорректно утверждать, что DFD — это просто предшественник UML.
Для себя я вывел следующую формулировку:
DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.
Зачем нужна нотация DFD?
Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – в таблице ниже:
Сам я пользуюсь только одним из вариантов, по Гейну и Сарсону. Но когда я изучал материал перед написанием этой статьи, я увидел эту таблицу сравнения. Считаю, что она важна не столько для выбора варианта синтаксиса, он будет зависеть, скорее от выбора программного обеспечения для создания нотаций и ваших личных предпочтений, сколько как наглядная иллюстрация того факта, что в DFD нет жесткого синтаксиса, как, например, в BPMN. Здесь можно использовать разные варианты, главное, чтобы они были понятны вам и вашим клиентам. Нотации DFD — удобный инструмент для создания нерегламентированных диаграмм, которые можно сделать быстро и с максимумом свободы.
Применяется этот вид нотации в случае, когда требуется описание системы как хранилища данных. Т.е. нотация должна наглядно ответить на вопросы:
Как создавать нотации DFD
Давайте для примера рассмотрим нотацию автоматизации продаж. Допустим, у нас есть клиент, который делает заявку через сайт или по телефону. Есть менеджер, который регистрирует эту заявку. Таким образом, в системе появляются данные – клиент и его заказ. Работник склада должен это увидеть и произвести отгрузку товара с оформлением всех необходимых документов и передать документы клиенту.
Последовательность получается такая:
С точки зрения DFD у нас имеются:
И декомпозиция основного элемента нашей диаграммы:
Где используются DFD нотации
DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:
Например, для выявления проблем документооборота, дублирования документов или, наоборот, недостающей документации или электронных данных в системе, очень удобно создать отдельно – описание бизнес-процесса, а потом к нему – DFD-нотацию. Либо наоборот, предварительно для понимания основ работы бизнеса и особенностей реализации документооборота создается DFD-нотация. Она помогает выявить, например, отсутствие в системе автоматизации важных документов, которые на самом деле создаются (на бумаге), но в системе никак не отображаются. А потом уже строится оптимизированный бизнес-процесс с учетом выявленных нюансов документооборота.
DFD нотации – это просто!
Я считаю, что DFD нотации – это действительно много проще, чем это кажется на первый взгляд. Главное, четко понимать ограничения построения этого типа диаграмм (отсутствие условий, времени и т.д.) и применять их там, где именно такой подход окажется удобнее. Возможно, вы найдете собственные варианты применения DFD, которые я выше не описал. В моем перечне присутствуют только те варианты, которые я использую на практике.
Что в DFD-нотациях особенно удобно, здесь не обязательно придерживаться строгих правил и синтаксиса, как, например, в BPMN. Эти нотации не будут исполнимыми, они нужны для понимания особенностей документооборота, структуры и последующей работы с данными. А потому, если ваша диаграмма понятна и вам, и заказчику, какие-то отступления от стандартов DFD вполне допустимы.
Рисовать диаграммы DFD можно, в принципе, где и как вам удобнее. Но если вы хотите работать с декомпозицией, выстраивать систему на разных уровнях детализации, то «рисовалки» (Visio, Paint и тому подобные) придется забыть. Вам потребуются специализированные программы для моделирования.
Лично я пользуюсь программой ERwin и всем ее рекомендую. Одна из причин моего выбора – это особенности декомпозиции. В ERwin, как и в некоторых других подобных системах, существует возможность декомпозирования DFD-процессов в формате IDEF3, т.е. основная диаграмма будет в формате DFD, и на самом общем уровне вы будете видеть основные потоки данных и «узлы» их обработки. А при декомпозиции вы сможете использовать уже процессный подход, что также бывает очень удобно для разработки крупных систем или работе с разными подразделениями бизнеса.
Вопросы и ответы
В чем разница между DFD и UML?
Существует язык создания нотаций UML, который также позиционирует себя как нотации, основанные на работе с данными. Но при этом UML — это уже язык программирования, здесь есть жесткий синтаксис, требования, но и возможностей для описания различных функций также много больше. DFD — это нотации, которые применяются более свободно, подходят, скорее, для планирования, изучения возможных вариантов решения, обсуждения с заказчиком и т.д.
Если вы — разработчик, и знаете UML, волне возможно, что даже какие-то предварительные решения вам будет удобнее создавать в этой нотации. А для бизнес-консультанта DFD всегда будет удобнее в качестве инструмента, так как бизнес-консультанту не требуется подробное описание функций с точки зрения автоматизации, это — задача технических специалистов. Зато время и силы DFD значительно экономит.
При этом не стоит рассматривать DFD как упрощенный вариант UML. Не смотря на схожесть в подходе, это — разные инструменты, предназначенные для разных целей.
Какое количество элементов может использоваться в DFD?
В отличие от систем с жестким синтаксисом и регламентом, в DFD нет ограничения по количеству элементов, которые могут находиться на одной диаграмме. Для сравнения: в IDEF0 количество таких элементов, дальше — только детализация (декомпозиция) или разные нотации.
С одной стороны, это большой плюс, так как отсутствие ограничений дает максимум свободы и комфорта при составлении нотации. С другой стороны, этой свободой злоупотреблять не рекомендуется. Помните, чем больше элементов у вас на диаграмме, тем сложнее ее читать.
Можно ли использовать нотации DFD для работы с клиентами?
В принципе, запретить это делать никто не может. Более того, в ограниченных количествах как иллюстрацию к каким-то вашим пояснениям такие нотации прекрасно подойдут и при обсуждении особенностей проекта с клиентом. Но все же, клиенты обычно слабо разбираются в вопросах автоматизации, структуре хранения данных, возможностях обработки и т.д. Это все находится в компетенции разработчиков. А нотации DFD строятся с учетом особенностей работы с данными, потому я все же рекомендую применять их преимущественно при обсуждении проекта специалистами, при создании технического описания и задания разработчикам, для повышения понимания именно разработчиками сути и особенностей проекта. Неподготовленному заказчику даже объяснить особенности DFD-нотаций может быть сложно.
Основные компоненты DFD и их обозначения
Язык функциональной модели DFD
DFD-моделирование
Лекция 3
13.09.04.
DFD-модель используется для определения архитектуры функциональных требований, как существующей (as is), так и проектируемой (to be) систем. На стадии разработки проекта DFD-модель расширяется, утоняется, дополняется новыми конструкциями. С помощью информационной ERD-модели на стадии формирования требований выполняется концептуальное моделирование, т.к. именно архитектура данных является стабильной основой любой проблемной области, что делает данные естественной конструктивной основой построения ИС. В ходе разработки ERD-модель дополняется новыми конструкциями, описывающими представление данных на логическом уровне, пригодном для дальнейшей генерации схем БД.
DFD определяет внешние по отношению к разрабатываемой системе источники, истоки (адресаты данных), идентифицирующие процессы (логические функции), потоки данных связывающие один процесс с другим (-ими) и хранилищами (накопители данных, к которым организуется доступ). Содержимое каждого хранилища раскрывается в дальнейшем в архитектуре данных с помощью ERD-модели.
Потоки данных (потоки управления)
Arrow – являются инструментами для моделирования и передачи информации/материальных объектов их одной части системы в другую. Появление потока всегда активизируется процессом activity, поэтому один конец потока всегда связан с процессом, находящимся либо внутри ИС, либо вне ИС, инициируется внешней сущностью. Потоки изображаются именованными направленными линиями. Стрелка показывает направление, могут быть одно- или двунаправленными. Именование потока – существительное с определением.
| Элементы | Нотации DFD-компонентов | |
| Иордан | Гейн-Сарсон | |
| Поток данных |  | |
| Процессы |  |  |
Процессы представляют функциональную деятельность, связанную с обработкой информации (управление информацией) и материальных объектов. Назначение процесса – продуцирование выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса – отглагольное существительное. Процесс отображает набор логически связанных операций (одну операцию), производимых внутри системы.
| Элементы | Нотации DFD-компонентов | |
| Иордан | Гейн-Сарсон | |
| Хранилища данных |  |  |
Хранилище данных (date store) собирает и хранит информацию в промежутке времени между процессами. Имя хранилища – существительное.
| Элементы | Нотации DFD-компонентов | |
| Иордан | Гейн-Сарсон | |
| Внешняя сущность |  |  |
Внешняя сущность (external references) – объект, находящийся вне системы, но взаимодействующий с ней. Внешняя сущность – источник/потребитель информации или материальных объектов.
Словарь данных (репозиторий) используется для хранения метаданных (структуры потоков данных, хранилищ, определения и компонентов) для определения словаря данных используется специальный язык Бэкуса-Наура.
Описание ФТ к ИС начинают с построения контекстной диаграммы, которая является специальным видом DFD-модели, моделирующей систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешней средой, а именно: этот интерфейс определяют информационные потоки между системой м сущностью, с которой она должна быть связана. Каждый проект должен иметь только одну контекстную диаграмму (ее даже не нумеруют). Контекстная диаграмма в дальнейшем детализируется с помощью функциональной декомпозиции в DFD нижнего уровня. В процессе декомпозиции строится иерархия DFD с контекстной диаграммой в форме дерева и концевыми узлами этого дерева атомарными процессами, для которых могут быть с помощью специальных шаблонов или СЕЯ составлены алгоритмы и построен код приложения. Т.о. процесс декомпозиции осуществляется до концевых узлов дерева.
Зачем вам DFD-диаграммы или как описать движение потоков данных в бизнес-процессах
Рассмотрим еще одну нотацию моделирования, которая не часто используется для непосредственного описания бизнес-процессов, а потому редко применяется начинающими системными и бизнес-аналитиками. Читайте далее, что такое DFD-диаграмма, зачем она нужна и как ее использовать в проектах интеграции информационных систем и управления данными.
Что такое DFD-нотация и зачем она нужна
Хотя BPMN и EPC нотации позволяют отлично описать логику выполнения бизнес-процессов, о чем мы писали здесь и здесь, иногда требуется показать эту деятельность не с позиции совершаемых действий, а с точки зрения обрабатываемых данных. Иначе говоря, нужно ответить на вопросы, из каких источников данных приходят, как преобразуются и куда отправляются. Обычно такая задача возникает в проектах, связанных с управлением данными (Data Management) и интеграции информационных систем. Методы и способы интеграции ИС мы рассмотрим в другой раз, а пока сфокусируемся на описании движения потоков данных. Именно для этого и нужны DFD-диаграммы (Data Flow Diagram).
Подобно IDEF0, DFD-нотация относится к SADT-методологии и соответствует структурному подходу, поддерживая принципы декомпозиции, иерархической упорядоченности и смыслового разделения сущностей. Хотя DFD и не содержит логических операторов (XOR, AND, OR), которые мы разбирали здесь, а также имеет очень ограниченное число элементов, она отлично позволяет описать последовательность возникновения, изменения и преобразования данных через их движение между процессами и хранилищами. Существует 2 разновидности DFD-диаграмм (Гейна-Сарсона и Йордана-Де Марко), которые немного отличаются лишь обозначениями некоторых элементов.
Итак, DFD-диаграмма включает следующие компоненты:
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
Ближайшая дата курса
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.
Правил для построения DFD-диаграмм совсем немного, и все они очень простые:
Чтобы показать реализацию этих правил на наглядном примере, далее рассмотрим уже упоминавшийся кейс нашей системы генерации промокодов после прохождения тестов, которые дают возможность оплатить курс со скидкой. Описание этой системы с помощью UML-диаграмм изложено в прошлой статье.
Как построить диаграмму движения потоков данных: практический пример
В конце лета наша Школа прикладного бизнес-анализа запустила маркетинговую акцию для частных клиентов, выдавая промокод на скидку по определенному курсу после прохождения тематического теста на сайте. Таким образом, всю последовательность действий по генерации промокода и его применению можно упрощенно представить следующим образом:
Таким образом, здесь можно выделить следующие хранилища данных:
Чтобы визуально выделить процессы, которые совершает пользователь, на диаграмме они отмечены голубым цветом. А хранилища данных, которые видны пользователю – желтым. Это не соответствует правилам DFD-нотации, но и не нарушает их: о цветовой маркировке блоков в первоисточниках ничего не сказано. Вообще прием с цветовым выделением некоторых блоков довольно удобен – я часто использую его на практике, чтобы облегчить читателю чтение диаграмм. В итоге для этого примера была составлена следующая DFD-диаграмма, показанная на рисунке ниже (контекстная диаграмма здесь не отображена).
Практический пример DFD-диаграммы (кликабельно, нажмите для увеличения)
В реализацию пошли не все описанные идеи этого кейса, но основные задумки реализованы. Проверить, как работает выдача промокодов на оплату наших курсов по бизнес-анализу со скидкой мы можете, выполнив любой открытый тест на нашем сайте бесплатно и без регистрации. А научиться самостоятельно разрабатывать DFD-диаграммы и освоить другие нотации моделирования бизнес-процессов вам помогут мои авторские курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
Что такое диаграмма DFD и как ее создать?
Каковы ваши потребности в диаграммах?
содержание
Если вы грамотно выбрали программу для составления диаграмм DFD, вы без труда разберетесь в течении информационных потоков по своим системам. В этом руководстве вы найдете всю необходимую информацию о диаграммах DFD, включая основные определения, историю возникновения, а также символы и способы нотации. Вы познакомитесь с разными уровнями диаграмм DFD, научитесь различать их логические и физические варианты, а также найдете полезные советы по составлению диаграмм этого типа.
Читается за 10 мин.
Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.
Что такое диаграмма DFD?
Диаграмма DFD наглядно отображает течение информации в пределах процесса или системы. Для изображения входных и выходных данных, точек хранения информации и путей ее передвижения между источниками и пунктами доставки в таких диаграммах применяются стандартные фигуры, такие как прямоугольники и круги, а также стрелки и краткие текстовые метки. Диаграммы DFD варьируются от простейших набросков процессов (включая нарисованные вручную) до подробных многоуровневых схем с глубоким анализом способов обработки данных. Диаграммы DFD применяются для анализа существующих и моделирования новых систем. В лучших традициях визуализации данных диаграммы DFD часто наглядно «рассказывают» о процессах, которые сложно объяснить словами, и позволяют эффективно донести информацию и до «физиков», и до «лириков», то есть до всех участников организации — от разработчиков до генеральных директоров. Вот почему диаграммы DFD не утратили популярности за долгие годы существования. Однако стоит упомянуть, что хотя диаграммы DFD отлично подходят для программ и систем потоков данных, в наши дни они далеко не всегда отвечают требованиям ПО и систем, ориентированных на интерактивность, работу в реальном времени и базы данных.
Символы и способы нотации диаграмм DFD
Самые распространенные системы нотации DFD-схем названы в честь их создателей:
Основное различие между этими системами заключается в том, что методы Йордона-Коуда и Йордона-Де Марко для обозначения процессов применяют круги, а метод Гейна-Сарсона — прямоугольные блоки со скругленными углами (которые иногда называют «конфетками»). Безусловно, у этих методов имеются и другие различия. Главное — четко придерживаться выбранной системы нотации при работе с другими участниками проекта.
Подчиняясь правилам и инструкциям выбранной системы, символы отображают четыре компонента диаграммы DFD:
Правила и советы по построению диаграмм DFD
Уровни и слои DFD-схем: от контекстных схем до псевдокода
С помощью слоев и уровней диаграмму DFD можно дополнять всё большими и большими подробностями, фокусируя внимание на одном конкретном участке. Уровни диаграммы обозначаются цифрами 0, 1 или 2, причем иногда нумерация может продолжаться (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. Это быстро, легко и совершенно бесплатно.