Берримор, ты потерял рецепт овсянки? Не беда, нам поможет DFD!

16.08.21

Архитектура

Методология DFD наряду с нотациями IDEF0 и IDEF3 входит в тройку популярных методологий описания бизнес-процессов. Мы не говорим о современных нотациях eEPC или BPMN, мы говорим о классике.

 

— Это что… мясо, по-вашему?

— Овсянка, сэр… Маленькая птица… отряда воробьиных.

Вступление

Мы познакомились с двумя нотациями функционального моделирования:

  1. Нотация IDEF0 (методология моделирования – SADT).
    С ее помощью описывают бизнес-процессы верхнего уровня.
    Статья //infostart.ru/1c/articles/1408200/

     
  2. Нотация IDEF3 (диаграмма PFDD) (методология моделирования – WFD).
    С ее помощью описываются бизнес-процессы нижнего уровня.
    Часто используется совместно с нотацией IDEF0.
    Статья //infostart.ru/1c/articles/1494168/

     

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

  1. Гейна-Сарсона (Gane / Sarson);
  2. Йордона-Де Марко (Yourdon / DeMarco).

 

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

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

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

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

  1. Какова структура проектируемой информационной системы?
  2. Как информация и данные взаимодействуют с системой и циркулируют внутри проектируемой системы?
  3. Что необходимо, чтобы потоки информации в моделируемой системе были обработаны?

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

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

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

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

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

 

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

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

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

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

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

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

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

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

  1. Логическая DFD,
  2. Физическая DFD.

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

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

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

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

 

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

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

  1. Разработка программного обеспечения. Первично модели DFD возникли как раз для разработки именно программного обеспечения, и позднее стали использоваться в других областях. В области разработки программного обеспечения применяют как логические, так и физические DFD. Примеры для визуализации:
    1. Хранилища данных – это электронные таблицы и базы данных.
    2. Внешние сущности – клиенты или другие базы данных, в том числе, из других программ (интеграция и обмен данными).
    3. Процессы – это выполняемые функции и модули в системе.

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

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

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

  1. Анализ данных и бизнес-анализ. Нотации DFD легко применимы при анализе, когда систему необходимо рассмотреть с точки зрения документооборота. Она наглядно покажет, где хранятся данные, каким образом производится обмен данными и документацией, и где в этом процессе допущены ошибки организации бизнес-процессов передачи информации и иные вопросы. Использование в этой области методологии DFD помогают выявить отсутствие в информационной (или иной) системе важных документов (а они при этом могут просто создаваться на бумаге и в системе никак не отображаться). На основании проведенного анализа будет строится оптимизированный бизнес-процесс («to be») с учетом выявленных проблемных мест.

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

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

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

  1. Структурированный анализ (SA). В классическом, последовательно декомпозиционном (нисходящем) структурном анализе для системы «as is» строится логический DFD, для описания ее текущего ее состояния. А после проведенного анализа строится логический DFD «to be». Далее строятся нисходящие физические DFD, чтобы показать целевое физическое решение программного обеспечения, информационной системы в целом или ее частей.
  2. В офисной работе или описании процессов в офисе. Логический DFD используется для описания бизнес-работ, которые необходимы для функционирования офиса или иной деловой среды. Логический DFD «to be» поможет спроектировать новую работу офиса с учетом заданных ограничений и узких мест, блокирующих или мешающих работе всего процесса. Логический DFD сформирует основу для физического DFD, который в свою очередь визуализирует, как реализовать оптимизацию процессов.
  3. В здравоохранении. Физический DFD «as is» отобразит текущую систему потока данных, например, информацию о пациенте, ведении его карточки, приеме врачей и проч. Это будет использовано для последующей визуализации, логического DFD «as is». Такое моделирование поможет сформировать четкое представление о недостатках и требованиях к новой системе. А это будет основой для проектирования логического DFD «to be», а затем нового физического DFD «to be».
     

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

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

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

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

 

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

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

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

  1. Peter Coad and Ed Yourdon (Coad and Yourdon methodology) – методология Коада и Йордана.
  2. Ed Yourdon and Tom DeMarco (Yordon-DeMarco notation) – нотация Йордона-ДеМарко.
  3. Chris Gane and Trish Sarson (Gene-Sarson DFD Symbols or notation) – нотация Гейна-Сарсона.
  4. SSADM (Structured System Analysis and Design Methodology).

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

Например:

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

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

  1. Процесс (англ. Process) / Работа (англ. Activity), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «Создание клиента») или «Обработать заказ» (а не «Проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.
  2. Внешние сущности / Ссылки (англ. External Entity / External Reference). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных.
  3. Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.
  4. Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме. Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы. Но DFD не является описанием всего бизнес-процесса, она затрагивает меньше сущностей. Эта нотация помогает понять, из чего должна состоять информационная система и что нужно для автоматизации бизнес-процесса. В этой нотации описывается не столько непосредственно бизнес-процесс, сколько движение потоков данных.

 

Символ / Назначение

Гейна-Сарсона

(Gene-Sarson)

Йордона-ДеМарко

(Yordon-DeMarco)

Коад и Йордон

(Coad and Yordon)

SSADM

Функция / Процесс

Работа, действие, операция преобразования данных.

Выполняет какие-либо действия над данными, как например: создает, модифицирует, сохраняет, удаляет и т.д.

Внешняя сущность

Является источником или адресатом потока данных. Отображает внешние по отношению к системе сущности.

Хранилище данных

Используется для хранения данных

Поток данных

Объект. Потоки данных между процессами, хранилищами, внешними сущностями.

 

Процесс

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

Его основные характеристики:

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

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

 

Гейна-Сарсона

(Gene-Sarson)

Йордона-ДеМарко

(Yordon-DeMarco)

 

Внешняя сущность

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

Гейна-Сарсона

(Gene-Sarson)

Йордона-ДеМарко

(Yordon-DeMarco)

 

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

Хранилище данных (англ. Data store) – это элемент методологии DFD, представляющий внутреннее хранилище данных для процессов в системе.

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

Гейна-Сарсона

(Gene-Sarson)

Йордона-ДеМарко

(Yordon-DeMarco)

 

 

Поток данных

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

 

Контекстная диаграмма

Контекстная диаграмма – это важный элемент методологии DFD, а именно это корневая диаграмма, на которой изображены:

  1. Все «заинтересованные» внешние сущности, общающиеся с системой.
  2. Единственный процесс с номером «0», который изображает всю систему целиком.
  3. Основные потоки данных между системой и внешним миром.

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

 

Уровни декомпозиции DFD

Уровни DFD-модели (или декомпозиции) можно наглядно представить в виде следующей схемы:

Более детально они изображаются следующим образом:

  1. Первая диаграмма называется контекстной (уровень 0) и служит для обозначения рамок системы (задания контекста, в котором система работает).
  2. Диаграмма детализируется путем добавления новых уровней.
  3. На каждом уровне декомпозируется (строится отдельная диаграмма) один какой-то процесс с предыдущего уровня.

 

Нумерация объектов

Нумерация элементов на диаграмме – езе одно важное понятие. Как и в IDEF0 нумерация функциональных блоков имеет иерархических характер:

  1. Уровень 0 –0
  2. Уровень 1 –1, 2, 3, …
  3. Уровень 2 –1.1, 1.2, …, 2.1, 2.2, …
  4. Уровень 3 –1.1.1, 1.1.2, …, 1.2.1, 1.2.2, …
  5. и т.д.

 

Распространенные ошибки при использовании нотаций методологии DFD

  1. У процесса есть выходящие потоки, но нет входящих.
  2. Хранилище и внешний источник связаны напрямую.
  3. Поток идет напрямую в двух направлениях.
  4. Хранилища связаны напрямую. 

 

Пример изображения DFD в нотациях

 

Нотация Гейна-Сарсона (Gene-Sarson)

 

Нотация Йордона-ДеМарко (Yordon-DeMarco)

 

Приятного аппетита и успехов в визуализации с помощью DFD! :) 

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1422    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1640    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3828    0    ivanov660    10    

29

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1818    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    2858    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9582    0    1c-izhtc    37    

21

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1384    0    Ingraf    0    

15
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. gzharkoj 502 16.08.21 11:44 Сейчас в теме
По примеру есть вопрос. Хранилища имеет смысл показывать те, что относятся к рассматриваемой/проектируемой системе, то есть в них есть и входящий и исходящий поток, если поток только один, то это внешняя сущность. В вашем случае книга рецептов - это внешняя сущность.
2. rusmil 262 16.08.21 18:00 Сейчас в теме
Распространенные ошибки при использовании нотаций методологии DFD
1. У процесса есть выходящие потоки, но нет входящих.
2. Хранилище и внешний источник связаны напрямую.
3. Поток идет напрямую в двух направлениях.
4. Хранилища связаны напрямую. 

А могли бы Вы подробнее пояснить почему это ошибки на конкретных примерах ну или где об этом можно почитать?
Оставьте свое сообщение