Для чего нужна диаграмма dfd

Для чего нужна диаграмма dfd

6.8. Назначение и состав DFD

При построении функциональной модели системы альтернативой методологии IDEF0 является методология диаграмм потоков данных (Data Flow Diagrams, DFD). В отличие от IDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели «TO-BE».

Как и в IDEF0, основу методологии DFD составляет графический язык описания процессов. Авторами одной из первых графических нотаций DFD (1979 г.) стали Эд Йордан (Yourdon) и Том де Марко (DeMarko). В настоящее время наиболее распространенной является нотация Гейна-Сарсона (Gane-Sarson).

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

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

6.9. Элементы графической нотации DFD

Согласно DFD источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации [17, 19].

При построении диаграмм различают элементы графической нотации, представленные в табл. 6.1.

Таблица 6.1. Элементы графической нотации DFD

Далее в примерах будет использоваться нотация Гейна-Сарсона.

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

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

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

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

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

— «Ввести сведения о клиентах»;

— «Рассчитать допускаемую скорость»;

— «Сформировать ведомость допускаемых скоростей»

Номер процесса служит для его идентификации и ставится с учетом декомпозиции. В отличие от IDEF0 вложенность процессов обозначается через точку (например, в IDEF0 – «236», в DFD – «2.3.6»).

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

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

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

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

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

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

6.10. Правила и рекомендации построения DFD

Правила и рекомендации построения модели DFD в основном совпадают с принятыми в IDEF0. Часть из них приведена в подразд. 6.9.

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

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

Наличие только выходящих потоков из накопителя также является ошибкой. Прежде чем использовать данные из накопителя, они должны там появиться в результате работы какого-либо процесса (подсистемы, внешней сущности). Исключением из правил считается случай, когда накопитель является внешней сущностью. Тогда допускается наличие либо только входящих стрелок, либо только выходящих стрелок (см. рис. 6.23, накопитель «БД АРМ-П или СБД-П»).

6.11. Пример построения модели DFD для системы определения допускаемых скоростей

Описание задачи приведено в подразд. 6.6.

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

Рис. 6.23. Контекстная диаграмма системы определения допускаемых скоростей (методология DFD)

На этой диаграмме видно, что в качестве источника исходных данных для работы системы могут использоваться базы данных АРМ-П (АРМ службы пути) или СБД-П (Сводная БД – Путейский фрагмент), содержащие практически всю необходимую информацию по участкам дороги.

В то же время в системе оставлена возможность ее ручного ввода и корректировки. Несмотря на то, что БД АРМ-П или СБД-П по отношению к системе являются внешними сущностями, они, в целях лучшего восприятия, показаны в виде накопителя данных.

Дальнейший процесс проектирования состоит в построении диаграмм декомпозиции, которые строятся (показывают устройство) только для процессов или подсистем (систем).

Диаграмма декомпозиции первого уровня проектируемой системы приведена на следующем рисунке.

Рис. 6.24. Диаграмма декомпозиции первого уровня (методология DFD)

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

При построении диаграммы декомпозиции блоки системы в одних случаях показаны как процессы (имя начинается с глагола), в других – как подсистемы (имя начинается со слова «подсистема»). Это сделано в целях иллюстрации правил именования блоков. В то же время декомпозицию системы можно было бы представить, либо используя только процессы, либо только подсистемы.

Контекстная диаграмма и диаграмма декомпозиции выполнены с использованием BPwin 4.0.

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

— наличия у процесса относительно небольшого количества входных и выходных потоков данных (2–3 потока);

— возможности описания процессов в виде простого алгоритма;

— возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20–30 строк).

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

6.12. Расширения DFD для систем реального времени

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

Квазинепрерывный поток (лат. quasi – как будто, якобы) – поток данных, непрерывный во времени. Отображается линией с двумя стрелками на конце.

Рис. 6.25. Квазинепрерывный поток

Управляющий процесс – процесс, формирующий сигналы управления на выходе.

Рис. 6.26. Управляющий процесс

Управляющий поток – управляющая информация, запускающая процесс (подсистему) или изменяющая ход его выполнения.

Рис. 6.27. Управляющий поток

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

Накопитель управлений – накопитель управляющих потоков.

Рис. 6.28. Накопитель управления

На рис. 6.29 показан пример использования новых элементов на DFD.

Рис. 6.29. Фрагмент DFD системы реального времени

Вопросы для самопроверки

2. Дайте краткую характеристику моделей AS-IS, «TO-BE» и «SHOULD-BE».

13. Перечислите отличия методологии IDEF0 от 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 (диаграммы потоков данных)

В комментариях к одной из моих прошлых статей, посвященной 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 (Data Flow Diagram), входящую в состав функционального моделирования и предназначенную для моделирования информационный систем с точки зрения хранения, обработки и передачи данных, и ту, которая используется разработчиками информационных систем для разработчиков информационных систем. А также рассмотрим две нотации, разрабатываемые при описании моделей в методологии DFD:

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

Диаграмма потоков данных или DFD (Data Flow Diagram) – это методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Методологию DFD по праву считается одним из основных инструментов структурного анализа и проектирования информационных систем, существовавшею до широкого распространения и применения унифицированного языка моделирования создания абстрактных моделей систем UML (Unified Modeling Language).

Правильно построенная диаграмма в методологии DFD даст ответы на такие вопросы как:

Немного истории

Диаграммы потоков данных известны очень давно и были предложены Лари Константином в 70-е гг. ХХ века. Однако, есть еще более раннее их упоминание, относящееся к 1920-м гг. Так, в литературе упоминается возможное использования диаграммы для оптимизации пространства в офисе для работы клерков. При осуществлении реорганизации специалист обозначил кружком каждого клерка, а стрелкой – каждый документ, передаваемый между ними. Нарисовав таким образом диаграмму, он предложил схему оптимизации, в соответствии с которой клерки, осуществляющие максимальную передачу документов между собой, были посажены рядом, а клерки с небольшим взаимодействием – на большом расстоянии.

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

В литературе (Ковалев С. Настольная книга аналитика. Практическое руководство по проектированию бизнес-процессов и организационной структуры) можно встретить другое название этой диаграммы – диаграмма потоков объектов. Обоснование достаточно логичное: потоки данных, которые изображаются стрелками на диаграмме, представляют объекты в процессе их передвижения от одного действия (подпроцесса) к другому.

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

Логическая и физическая DFD

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

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

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

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

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

Таким образом, любая диаграмма потока данных (DFD) отображает поток информации для процесса или системы, тогда как логическая диаграмма предоставляет «что» происходит, а физическая – «как» это происходит. Это две разные точки зрения на один и тот же поток данных, каждая из которых предназначена для визуализации и уточнения системы.

Таким образом, визуализация в методологии DFD может быть представлена в двух вариантах:

Рассмотрим оба варианта.

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

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

Физическая DFD смотрит на то, как реализована система.

Использование DFD

Применение методологии DFD очень разнообразно:

Логический DFD «as is» фиксирует текущие и необходимые действия, требуемые для процесса. Логический DFD «to be» моделирует новый набор действий и функций.

Физический DFD «as is» отображает текущее программное обеспечение, оборудование, базы данных и людей для выполнения действий, тогда как физический DFD «to be» моделирует новую реализацию системы.

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

В области анализа так же применимы и логические, так и физические DFD.

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

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

DFD и другие нотации моделирования процессов

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

Различные инструменты моделирования (программные продукты) предоставляют возможность совместного использования нотаций, например, ERwin, позволяет декомпозирования DFD-модель верхнего уровня уже в нотации IDEF3. Таким образом, контекстная диаграмма будет в формате DFD, а декомпозированные процессы уже будут в формате IDEF3. Верхний уровень диаграммы – это основные потоки данных и «узлы» их обработки. А нижестоящие – это детализированные процессы. Такой подход очень удобен при разработки крупных систем или работе с разными подразделениями бизнеса.

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

Нотации и элементы, используемые при DFD-моделировании

Диаграммы потоков данных стали известны широкой публике с конца 1970-х годов благодаря книге «Структурное проектирование» пионеров вычислительной техники Эда Йордана и Ларри Константина («Structured Design» Yourdon & Constantine, 1974).

Наиболее распространенные нотации (системы символов):

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

Итак, в зависимости от используемой нотации графическое представление объектов элементов диаграмм будет различным. Однако базовыми понятиями диаграмм потоков данных являются 4 элемента:

Источник