Состав диаграмм потоков данных. Пример построения DFD модели Дайте определение внешней сущности dfd диаграммы

27.03.2022

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

Рис. 8.8.

В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона.

Для того чтобы дополнить модель IDEF0 диаграммой DFD , нужно в процессе декомпозиции в диалоге Activity Box Count "кликнуть" по радио-кнопке DFD . В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

(External Reference ) - добавить в диаграмму внешнюю ссылку ;
(Data store ) - добавить в диаграмму хранилище данных ;
Diagram Dictionary Editor – ссылка на другую страницу. В отличие от IDEF0 этот инструмент позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

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

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

Рис. 8.9.

В DFD работы (процессы ) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы , как IDEF0 (рис. 8.9) (блоки "Проверка и внесение клиентов", "Внесение заказов").

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

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

В отличие от стрелок, описывающих объекты в движении,

Пояснительная записка

по дисциплине

« Информационные технологии проектирования

радиоэлектронных средств»

Тема: «Использование технологии DFD»

Выполнил: студент гр. 4141 Понкин Д.О.

Руководитель: доцент Колуков В.В.

Дубна, 2012

Введение. 3

Состав диаграмм потоков данных. 3

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

Пример построение DFD-диаграммы.. 8

Выводы.. 10

Список литературы.. 11

Введение

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

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

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

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

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

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

Основными компонентами диаграмм потоков данных являются:

внешние сущности;

системы и подсистемы;

процессы (работы);

накопители данных;

потоки данных.

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

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

Рис. 1. Графическое изображение внешней сущности

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

Подсистема (или система) на контекстной диаграмме изображается так, как она представлена на рис. 2.

Рис. 2. Подсистема по работе с физическими лицами

(ГНИ - Государственная налоговая инспекция)

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

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

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

Рис. 3. Графическое изображение процесса

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

Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.

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

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

Рис. 4. Графическое изображение накопителя данных

Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

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

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

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

Материал из ПИЭ.Wiki

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

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

Основными элементами диаграмм потоков данных являются :

внешние сущности;

процессы;

накопители данных;

потоки данных.

Внешние сущности

Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации. В качестве внешней сущности на DFD диаграмме могут выступать заказчики, поставщики, клиенты, склад, банк и другие. К сожалению, DFD методология не оформлена как стандарт. По этой причине в диаграммах потоков данных используются различные условные обозначения. На рисунке 1 показаны символы внешних сущностей, используемые в нотациях «Yourdon and Coad Process Notation» и «Gane and Sarson Process Notation».

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

Процессы

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

Накопители данных

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

Накопители данных являются неким прообразом базы данных информационной системы организации.

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

Потоки данных

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

В DFD используются следующие типы объектов: · работа (activity) - синоним работе в IDEF0 и IDEF3; · внешняя сущность (external entity) - объекты - источники/получатели информации/данных, изменяемых или используемых в данной функции. · стрелка (data flow) - обозначение потока информации (данных); · data store (хранилище данных) - любой механизм или абстракция (например, запись в базе данных), в которой хранятся данные. Потоки данных между работами в DFD возможны не только опосредованно, через хранилища данных, но и непосредственно между работами, если данные не поступают сначала в хранилище. Нотации IDEF0, IDEF3 и DFD могут быть последовательно использованы при все более и более глубокой проработке модели организации, завершающим этапом которой может быть детальное описание бизнес-процессов и информационной системы организации

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

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

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

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

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

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

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

Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь, может быть детализирован при помощи ДПД или миниспецификации. При детализации должны выполняться следующие правила: правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме; правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

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

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

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

Тема 8. Моделирование потоков данных

Общие положения. 1

Модель DFD.. 3

Виды DFD нотаций.. 3

Структура DFD модели.. 4

Основные элементы DFD и их назначение. 6

Выводы: 11

Общие положения

Существует легенда о том, как появились DFD.

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

Пример DFD диаграммы показан на схеме (Рис. 87).

Рис. 87. Пример DFD диаграммы

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

При проведении проекта создания ИС нотация DFD может использоваться в качестве основной нотации функционального моделирования, однако, часто она применяется как дополнительная по отношению к IDEF0 (Рис. 88).

Информационные сети" href="/text/category/informatcionnie_seti/" rel="bookmark">обработки информации . В отличие от IDEF0, где система рассматривается как взаимосвязанные функциональные блоки, а дуги представляют собой жесткие взаимосвязи, стрелки в DFD показывают лишь то, как объекты (включая данные) движутся от одной работы к другой. DFD отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных.

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

DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.

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

Модель DFD

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

ОПР .: В DFD (Data Flow Diagram), модель системы определяется как иерархия диаграмм потоков данных, описывающих процессы преобразования информации от момента ее ввода в систему до выдачи конечному пользователю. Диаграммы верхних уровней иерархии - контекстные диаграммы, задают границы модели, определяя её окружение (внешние входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются при помощи диаграмм следующих уровней.

Так как DFD не является стандартом, на настоящее время нет единой нотации со своими однозначно определенными примитивами. Для представления моделей применяются ряд различных нотаций DFD. Наибольшее распространение среди них получили нотации Гейна-Сарсона и Йодана/де Марко (Рис. 89). Помимо этих нотаций имеются и другие. Например, нотация применяемая в CA BPwin имеет свои особенности.

Рис. 89. Наиболее распространенные нотации DFD

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

Структура DFD модели

Иерархия DF диаграмм показана на схеме (Рис. 90).

Колл" href="/text/category/koll/" rel="bookmark">коллективы разработчиков.

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

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

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

– возможности описания преобразования данных процессом в виде последовательного алгоритма;

– выполнения процессом единственной логической функции преобразования входной информации в выходную;

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

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

Основные элементы DFD и их назначение

Синтаксис DFD включает четыре основных элемента:

– поток данных;

– процесс;

– хранилище;

– внешняя сущность.

Рассмотрим эти элементы подробнее.

Поток данных

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

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

Рис. 91. Поток данных

В отличие от дуг в IDEF0 потоки данных в DFD могут быть не только однонаправленными, но и двунаправленными.

Процесс

ОПР .: Процесс преобразует значения данных.

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

Как уже говорилось ранее из-за отсутствия единого стандарта, объекты DFD могут иметь разное обозначение (Рис. 92).

Особо следует подчеркнуть, что в отличие от SADT, в DFD все стороны блока равнозначны (это очевидно, если посмотреть на обозначение процесса в нотации Йодана/де Марко). Другими словами, в отличие от IDEF0 диаграмм, в DFD диаграммах не используются стрелки управления для обозначения правил выполнения действия и стрелки механизмов для обозначения требуемых ресурсов.

Базы данных" href="/text/category/bazi_dannih/" rel="bookmark">базы данных информационной системы организации.

ОПР . 2: ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

На диаграмме хранилище обозначаются как показано на схеме (Рис. 93).

https://pandia.ru/text/80/146/images/image009_14.gif" width="555" height="183 src=">

Рис. 94. Обозначение внешней сущности в разных нотациях DFD

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

https://pandia.ru/text/80/146/images/image011_14.gif" width="567" height="394 src=">

Рис. 96. Пример DFD диаграммы

Выводы:

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

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

Серьезными недостатками DFD является то, что:

– во-первых, выразительная сила нотации DFD оказывается недостаточной при анализе модели, выявлении «узких мест», поиске путей усовершенствования и т. д.;

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

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

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

Учитывая то, что тенденции IT-ранка однозначно показывают тупиковость пути «лоскутной автоматизации» и необходимость отхода от самописных систем, становится очевидным, почему в деятельности консалтинговых компаний резко сокращается применение нотации DFD и, наоборот, резко возрастает популярность IDEF0.