Что такое dfd и для чего она используется
Что такое dfd и для чего она используется
DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.
Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.
Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям.
Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).
Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.
Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, диаграмма Диаграмма вариантов использования.
Что такое DFD (диаграммы потоков данных)
DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Википедия
По моему мнению, определение из русскоязычной Википедии, несколько перегружено информацией и, в результате, излишне сложно для понимания. Кроме того, лично я считаю, что DFD и UML — это разные инструменты, а потому некорректно утверждать, что DFD — это просто предшественник UML.
Для себя я вывел следующую формулировку:
DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.
Зачем нужна нотация DFD?
Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – в таблице ниже:
Сам я пользуюсь только одним из вариантов, по Гейну и Сарсону. Но когда я изучал материал перед написанием этой статьи, я увидел эту таблицу сравнения. Считаю, что она важна не столько для выбора варианта синтаксиса, он будет зависеть, скорее от выбора программного обеспечения для создания нотаций и ваших личных предпочтений, сколько как наглядная иллюстрация того факта, что в DFD нет жесткого синтаксиса, как, например, в BPMN. Здесь можно использовать разные варианты, главное, чтобы они были понятны вам и вашим клиентам. Нотации DFD — удобный инструмент для создания нерегламентированных диаграмм, которые можно сделать быстро и с максимумом свободы.
Применяется этот вид нотации в случае, когда требуется описание системы как хранилища данных. Т.е. нотация должна наглядно ответить на вопросы:
— Из чего состоит информационная система?
— Что нужно, чтобы обработать информацию?
Непосредственно DFD нотация состоит из следующих элементов:
— Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.
— Внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных.
— Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.
— Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.
Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы. Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес-процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных. Для работы с процессами я рекомендую использовать BPMN или IDEF3 (о ней я расскажу в другой раз).
Как создавать нотации DFD
Давайте для примера рассмотрим нотацию автоматизации продаж. Допустим, у нас есть клиент, который делает заявку через сайт или по телефону. Есть менеджер, который регистрирует эту заявку. Таким образом, в системе появляются данные – клиент и его заказ. Работник склада должен это увидеть и произвести отгрузку товара с оформлением всех необходимых документов и передать документы клиенту.
Последовательность получается такая:
1) Клиент предоставляет свои данные и заявку.
2) Менеджер проверяет и вносит полученные данные в систему.
3) Работник склада формирует документы, например, расходную накладную, и отгружает товар.
4) Клиент получает товар и пакет документов к нему.
Эту последовательность действий нам необходимо увидеть с точки зрения хранения данных и работы с ними в IT-системе.
С точки зрения DFD у нас имеются:
Какие правила необходимо знать, чтобы создать 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-нотаций может быть сложно.
H Что такое 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 и для чего она используется
Дата публикации: 10.06.2014
Библиографическая ссылка:
Морозов Д.А. Применение нотации DFD в моделировании внешних схем // Портал научно-практических публикаций [Электронный ресурс]. URL: https://portalnp.snauka.ru/2014/06/2015 (дата обращения: 24.12.2021)
Морозов Д.А. Студент 2 курса
ФГБОУ ВПО МГТУ им.Носова Г. Магнитогорск
Аннотация
В данной статье изложен небольшой исторический экскурс о возникновении бизнес-моделирования. Затрагиваются преимущества и недостатки DFD нотации, ее основные компоненты и применение.
Application modeling notation DFD external circuitry
Morozov D.A.2nd year student
FGBOU VPO MGTU im. Nosova Magnitogorsk
Annotation
This article describes a small historical review of the occurrence of business modeling. Affected by the advantages and disadvantages of DFD notation, its main components, and applications.
Всю историю развития бизнес-моделирования, с точки зрения управления организацией, можно разделить на четыре этапа.
70-е годы 20-го века.
Началось осуществление задумки по реализации сложных, масштабных проектов со специалистами различных предметных областей: транспортные сети, системы вооружения и т.д. Пришло время достаточно серьезных изменений в условиях функционирования производственных и коммерческих компаний. После проведения анализ всех проблем, возникших в деятельности организации, было принято решение рассматривать предприятия, как организационно-технические системы, которые включают:
В свою очередь, все это привело к необходимости в разработке адекватных способов этих элементов в структурированном связном виде. Одна из самых известных методологий по описанию организации с точки зрения организационно-технических систем – это методология SADT. В 1973 году ее разработал американец Дуглас Росс.
80-е годы 20-го века.
Появление персональных компьютеров, а также разработка систем автоматизации, дало новый ощутимый толчок в дальнейшем развитии способов описания деятельности различных организаций. Из-за высокой потребности в автоматизации бизнес-процессов моделирование деятельности предприятий вышло на новый уровень. Так, например, ниже представлены несколько небезызвестных методологий, описывающих деятельность предприятий:
Каждая из этих методологий хороша по своему при решении каких-то конкретных задач, поставленных перед специалистом по автоматизации. В зависимости от этих задач и выбирается определенная методология.
Во времена бурного развития информационных технологий, дотированных 80-и годами, объемы разработки также стали расти. Остро встала проблема в нехватки «правильно» спроектированного программного обеспечения. Это привело к созданию отдельного направления программотехники CASE-технологий.
Преимущество CASE-средств заключается в том, что они позволяют отойти от достаточно многих сложностей «ручного» применения методологий моделирования бизнес-процессов. Такое средство является отличным способом автоматизации работы специалистов по разработке программных обеспечений. Например: аналитиков, программистов, проектировщиков, технических писателей и т.д. Средства предназначены для графического описания процессов, обеспечение удобной среды для командной работы специалистов на этапе анализа, проектирования, разработки, сопровождения систем ПО.
90-е годы 20-го века
С наступлением 90-х годов встал вопрос о решении задач, тесно связанных, с организационными вопросами по управлению компаниями. В результате на западе появились первые программные продукты для этой цели. Поспособствовали этому две причины.
В результате CASE средства стали использовать не только для автоматизации деятельности предприятий, но и для решения ряда задач бизнес-анализа.
Благодаря соответствующим ПО бизнес-моделирование не стоит на месте и продолжается развиваться в наши дни. Сейчас из него «вытекает» новая методология – бизнес-инжиниринг. Суть бизнес-инжиниринга сводиться к анализу и совершенствованию деятельности организации, путем применения ее бизнес-моделей, которые в свою очередь созданы с применением процессного подхода.
Data Flow Diagrams (DFD) – диаграмма потоков данных. Так называется методология с помощью, которой проводится графический и структурный анализ. Диаграмма описывает внешние по отношению к системе источники, логические функции хранилища и потоки данных к которым запрашивается доступ.
DFD довольно популярный инструмент структурного анализа и проектирования информационных систем (ИС). Несмотря на наметившуюся тенденцию, в последние годы, перехода от структурного анализа к объектно-ориентированному подходу устаревшие системы структурного анализа прочно занимают свою нишу.
Модель DFD относится к иерархическому типу. Каждый её процесс можно продекомпозировать. Другими словами, разбить на отдельные, структурированные составляющие, отношения между которыми могут быть показаны в этой же нотации, но на отдельной диаграмме. После того, как требуемая глубина декомпозиции достигнута, в процессе нижнего уровня прописывается небольшая спецификация в текстовом виде.
Нотация DFD отлично подходит для создания контекстной диаграммы. Таковой служит самая верхняя диаграмма в иерархии DFD. Она служит для четкого определения границ между разрабатываемой системой и средой.
Основные компоненты DFD
Внешняя сущность – физическое лицо или материальный объект, которые являются источниками либо приемниками информации. Например: персонал, заказчик, поставщик, склад. В процессе построения сложной модели внешние сущности могут быть представлены в общем виде на контекстной диаграмме, которая выше уже была затронута, или же могут быть декомпозированы на целый ряд других подсистем.
Процесс – конвертирует входные потоки данных в выходные, опираясь, при этом на определенный алгоритм. Несколько примеров физической реализации процесса:
Для идентификации блоков процесса, каждому присваивается номер. Имя процесса должно содержать активный, недвусмысленный глагол в неопределенной форме. Например: создать, рассчитать, определить, получить. Полностью же наименование процесса должно выглядеть примерно так – «Проверить плательщика на задолженность ».
Хранилище – абстрактное устройство, предназначенное для хранения информации. Информацию можно поместить в хранилище в любой удобный момент и также извлечь ее оттуда, при этом делая это различными способами. Хранилище является неким прообразом будущей базы данных и характеристики, хранящихся в нем данных должны полностью соответствовать модели данных.
Поток данных представляет собой некоторое соединение между источником и приемникам, передающее информацию. На DFD диаграмме потоки данных изображаются обыкновенными стрелками, где стрелка указывает направление потока. На диаграмме не должно быть безымянных стрелок, поэтому каждый поток должен иметь название, отражающее его содержание.
Достоинства и недостатки DFD нотации
У каждого инструментария предназначенного для бизнес-моделирования, есть свои плюсы и минусы. Остановимся по подробнее на Data Flow Diagrams.
К главным преимуществам можно отнести:
Из главных недостатков можно выделить: невозможность анализа временных промежутков в процессе преобразования данных, необходимость ввода управляющих процессов.