дата флоу что это
Что такое 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-нотаций может быть сложно.
Реализация Unidirectional Data Flow в супераппе. Часть I
Привет, я Антон, iOS-разработчик в inDriver. К компании я присоединился год назад, став одним из первых разработчиков в новой платформенной команде. Перед платформенными командами, в отличие от продуктовых, стоят задачи по разработке, а не по продукту как таковому. Мы выделили основные направления: создание общих компонент и стандартов разработки, а также развитие и поддержка архитектуры проекта. В этой статье остановимся на архитектуре. Разберем, с какими проблемами я столкнулся в процессе ее масштабирования, какие ошибки допустил и как исправил. Обо всем по порядку.
UPD: технические детали подробнее рассказаны во второй части.
Для начала расскажу об iOS-проекте inDriver на момент создания платформенной команды. inDriver — ride-hailing стартап, созданный в 2013 году в Якутии. За 8 лет существования компания быстро росла: запускалась в новых странах, а в приложении открывались новые фичи и модули — мы называем их вертикали. Со временем приложение inDriver превратилось в суперапп, в котором просто вызвать грузовую машину, такси по городу или за город, заказать курьера или найти специалиста для решения бытовых задач.
Разнообразие сервисов повлияло на код проекта. Изначально написанный на Objective-C, он лавинообразно расширялся, а потом стал обрастать новым кодом на Swift. Времени на тесты и детальное продумывание архитектуры у разработчиков не было — чем больше становился проект, тем сложнее его было поддерживать.
Продуктовые команды работали над разными вертикалями и не имели никаких ограничений в выборе архитектуры. Поэтому, если какая-то команда создавала переиспользуемую логику или UI, использовать ее можно было только для своей вертикали. В результате вертикалям приходилось дублировать код, даже если его уже написали в другой вертикали. Код имел классические проблемы быстрорастущего стартапа и работать с ним становилось сложнее.
Мы решили, что хватит это терпеть, и пришли к выводу, что нужна общая архитектура для приложения. Это позволило бы ускорить разработку с помощью написания общих компонент, которые можно использовать во всех вертикалях. Кроме того, это упростило бы ротацию разработчиков между вертикалями и понимание кода на код-ревью. Мы сформулировали требования для общей архитектуры:
Поддержка модуляризации. Мы делили приложение на небольшие части с точки зрения бизнес-логики, UI и фич. Модуляризация позволяет отвязать код вертикалей друг от друга. Чем меньше код одной вертикали влияет на другую, тем меньше возможность получить неожиданный баг. С другой стороны, модуляризация позволяет создать переиспользумые компоненты и подключать их в нуждающихся вертикалях. Благодаря этому пишется меньше кода и ускоряется процесс разработки.
Быстрое и эффективное тестирование кода. Любой код без должного внимания со временем становится легаси-кодом. Код в inDriver не стал исключением. Согласен с Майклом Физерсом, что легаси-код — это код, не покрытый тестами. Не знаю другого способа предотвратить превращение кода в легаси, кроме покрытия тестами (если знаете, можем обсудить их в комментариях). Но с тестами есть одна большая проблема — их бывает сложно и долго писать. По этой причине многие разработчики часто отказываются от тестов, оправдывая это тем, что бизнес не дает на них время. В результате код неминуемо превращается в легаси. Наша архитектура должна легко и быстро тестироваться.
Возможность быстро перейти на SwiftUI. На примере Objective-C мы убедились, как болезненно, когда технологии меняются, а код устаревает. Хороший код на этом языке программирования сейчас является обузой. Проблемы, уже решенные в Swift, остаются без поддержки для Objective-C. Да и найти разработчиков на Objective-C становится сложнее. Поэтому приходится тратить усилия по переписыванию проектов на Swift.
Подозреваю, что со временем такая же судьба ждет и UIKit. Apple все активнее развивает SwiftUI. Не хочется попасть в ситуацию как с Objective-C и переписывать весь код под SwiftUI. Мы пока не используем SwiftUI в продакшене, но решили подстраховаться и учесть это, чтобы наша архитектура поддерживала как UIKit, так и SwiftUI. При необходимости перехода на SwiftUI, мы бы с легкостью смогли это сделать, переписав UI-слой, но не трогая бизнес-логику.
Прежде чем вводить новую архитектуру и переписывать старый код мы посмотрели, какие подходы уже реализованы в проекте. Помимо MVC (тот, что Massive) в проекте был Clean Swift и реализация Redux в виде фреймворка Unicore. На нем была написана одна фича и самая свежая вертикаль. До этого с Redux мы не работали. Был опыт работы с RxSwift и RxFeedback, поэтому некоторые вещи из Redux оказались знакомы.
Мы решили детальнее посмотреть на Redux, так как он уже был в проекте и многие разработчики успели с ним поработать. Redux — изначально JS-библиотека, которая создана для веба и работы в связке с React. Помимо Redux, в вебе множество схожих библиотек и даже целые языки, например, Elm. Да и на Swift уже хватает похожих решений: ReSwift, TCA, RxFeedback. Их объединяет использование шаблона Unidirectional Data Flow (UDF). Чтобы понять, какой из фреймворков больше подойдет команде, разберу, что собой представляет Unidirectional Data Flow.
Основная идея Unidirectional Data Flow заключается в том, чтобы данные в приложении двигались только в одном направлении: от модели приложения к UI, но не обратно. Если в UI что-то произошло, он никак не пытается интерпретировать эти события. Все, что делает UDF — отправляет события в модель, которая решает, как обновить состояние системы.
В такой схеме мы легко добиваемся того, чтобы данные, передаваемые в UI, были иммутабельными. UI получает на вход данные и отображает их, а если надо что-то изменить, UI отправляет событие (Action) в модель и ждет, когда к нему придут уже обновленные данные.
Разные фреймворки по-разному реализуют модель приложения. Попробуем найти в них общие части. Привожу названия из Redux, в скобках — альтернативные именования:
State (Model) — состояние системы. Это неизменяемые value-типы, которые описывают текущее состояние приложения.
Action (Event/Message) — события в системе. Помогают из UI сообщить о произошедших изменений и уведомить об этом модель.
Store (Core) — агрегирующая сущность. Хранит в себе State и запускает Reducer. В качестве интерфейса предоставляет возможность отправить Action и подписаться на обновление State. Чаще всего один на приложение.
Вместе это работает так:
В UI произошло событие, и он отправляет в Store Action.
Store вызывает Reducer и передает в качестве параметров текущий State и пришедший Action. На выходе — новый State, который сохраняется в Store вместо старого.
Store оповещает UI и передает ему обновленный State.
Может показаться, что такой подход далек от мобильной разработки и не подходит ни для iOS, ни для Android. На самом деле и Apple, и Google используют Unidirectional Data Flow в своих фреймворках. Если внимательно присмотреться к схеме работы SwiftUI, мы обнаружим много сходств с нашей схемой. Google же прямым текстом упоминает Unidirectional Data Flow в документации по Jetpack Compose.
Рассмотрим плюсы Unidirectional Data Flow:
Четкое разделение доменной логики и сайд-эффектов. Принцип не новый и давно используется в функциональном (чистые функции, монады) и объектно-ориентированном программировании (CQRS). Однако большинство мобильных архитектур не акцентируют внимание на том, как реализовывать модель приложения, и бизнес-логика часто просачивается в Controller / Presenter / Interactor или View. UDF дает четкие инструкции, как организовать доменный слой приложения и получить хорошую переиспользуемую модель.
Легкое написание тестов. Так как бизнес-логика реализована в чистых функциях, протестировать ее просто. UI зависит только от полученных данных и занимается исключительно их рендерингом. Так удобно тестировать UI через snapshot-тесты. Достаточно сконфигурировать нужный State и проверить, что UI корректно рендерит его.
Но есть и ряд минусов:
1. Сложности с модуляризацией. В нашем приложении уже были модули. Вся бизнес-логика была собрана в модуле Core и каждой фиче нужно импортировать этот модуль себе:
С одной стороны, такое разделение позволяло отделить модель приложения от UI. C другой, модель получилась монолитной и сложной. Не было возможности отделить часть логики и использовать отдельно. Каждая фича знала о модели всего приложения, а, значит, и о других фичах. С таким подходом дальнейшее масштабирование проекта лишь усугубило бы текущие проблемы.
2. Проблемы с производительностью. Большинство UDF-фреймворков предполагают наличие одного Store. Это позволяет гарантировать единый источник правды и обновлять State в одном месте. Но такой подход ведет к проблемам с производительностью. Из-за того, что в Store приходят Action со всего приложения, обновления AppState могут происходить очень часто. Это создает большую нагрузку как на Reducer, так и на UI.
Существующий в проекте Redux соответствовал 2 из 3 наших требований к общей архитектуре. Во-первых, он легко покрывается тестами, как со стороны модели, так и UI. Во-вторых, State, Action и Reducer не зависят от UIKit, и вся модель приложения легко подключается к SwiftUI. Самой большой проблемой оказалась модуляризация проекта. В следующей статье расскажу, как мы справились с модуляризацией Unidirectional Data Flow и что из этого вышло.
data flow
Смотреть что такое «data flow» в других словарях:
data flow — noun (computing) An approach to the organization of complex algorithms and machines, in which operations are triggered by the arrival of data • • • Main Entry: ↑data … Useful english dictionary
Data Flow — [engl.], Datenfluss … Universal-Lexikon
data flow — informacijos srautas statusas T sritis automatika atitikmenys: angl. data flow; information flow vok. Datenfluß, m; Datenstrom, m; Informationsfluß, m rus. информационный поток, m; поток информации, m pranc. flux d informations, m … Automatikos terminų žodynas
data flow — noun a) The route between origin, via nodes, to a destination taken by a packet of data b) The transfer of data between the components of a computer … Wiktionary
Data-flow analysis — is a technique for gathering information about the possible set of values calculated at various points in a computer program. A program s control flow graph (CFG) is used to determine those parts of a program to which a particular value assigned… … Wikipedia
Data flow diagram — example.[1] A data flow diagram (DFD) is a graphical representation of the flow of data through an information system, modelling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be… … Wikipedia
data flow diagram — UK US noun [C] (ABBREVIATION DFD) ► a drawing, often produced by a computer, that shows how and in what order information is dealt with in a system: »Use a data flow diagram to show the relationships between the business processes within an… … Financial and business terms
data flow chart — data flow diagram A chart that illustrates the way in which specified data is handled by a computer program. Its purpose is to specify the data, to show where it is used or changed, where it is stored, and which reports use it … Accounting dictionary
data flow chart — data flow diagram A chart that illustrates the way in which specified data is handled by a computer program. Its purpose is to specify the data, to show where it is used or changed, where it is stored, and which reports use it … Big dictionary of business and management
data flow diagram — data flow chart … Accounting dictionary
data flow diagram — noun A type of flow chart; a description of data and the manual and machine processing performed on the data as it moves and changes from one stage to the next. It also includes the locations where the data are placed in permanent storage (disk,… … Wiktionary
Берримор, ты потерял рецепт овсянки? Не беда, нам поможет 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 элемента: