Как использовать их для описания движения данных в бизнес процессах

Что такое DFD?

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

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

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

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

Сейчас же речь пойдет о таком инструменте как DFD (Data Flows Diagrams) – диаграммах потоков данных.

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

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

Аккуратная и четкая DFD может графически отобразить значительную часть требований к системе. Она может быть ручной, автоматизированной или сочетать оба способа.

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

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

Пример использования DFD

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

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

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

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

Преимущества использования DFD

• Создание моделей на разных уровнях детализации
• Представление бизнес-процессов и бизнес-данных
• Улучшенное понимание работы бизнеса

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

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

Движение данных

Теперь давайте поговорим о движении данных. Что тут имеется в виду? С потоками данных мы сталкиваемся не только при решении задач, но и в реальной повседневной жизни.

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

Примеры движения данных

• Документооборот: обращения в работе, на подписании или в архиве
• Товарооборот: перемещение товаров между складом и магазинами
• Финансовые транзакции: проведение платежей и получение товаров

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

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

Схематически этот процесс можно представить так:

Нотация DFD

Нотация DFD включает всего лишь 4 основных элемента: процесс, внешняя сущность, хранилище данных и поток данных.

При этом есть два варианта графического отображения этих элементов: Юрдана (Yourdon) и Гейна-Сарсона (Gane-Sarson).

Описание нотации DFD

С помощью этой нотации можно описать любые действия и она может дать понимание того из чего должна состоять система, но в то же время DFD не может быть инструментом для описания бизнес-процесса. В ней нет такого параметра как время, нет понятия условия и “развилки”, которая может возникнуть при том или ином условии. В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных. Для работы с процессами можно использовать BPMN или IDEF3.

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

Правила для построения не так уж и много:

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

Контекстная диаграмма в нотации Йордана де Марко содержит три основных компонента:

1. Внешняя сущность
2. Поток данных
3. Хранилище данных

DFD первого уровня

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

Построенная диаграмма первого уровня

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

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

Теперь давайте рассмотрим несколько примеров (а один я распишу пошагово).

Пример 1. Приготовление кофе в кофейном автомате

Как происходит процесс приготовления кофе в кофейном автомате.

Контекстная диаграмма для этого процесса будет выглядеть следующим образом:

Пример DFD: приготовление кофе в кофейном автомате. Контекстная диаграмма

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

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

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

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

Когда заказ оплачен, ингредиенты и рецепт передаются в процесс Приготовить кофе. Готовый напиток наливается в стаканчик, переданный из Склада стаканов. Это происходит в процессе Налить кофе. В результате клиент получает готовый напиток.

Пример 2. Обработка заявки клиента

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

Последовательность получается такая:

С точки зрения DFD у нас имеются:

Контекстная диаграмма для этого процесса будет следующая:

Пример 3. Отгрузка товара клиенту

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

Обработка заказов в компании

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

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

Разбиение процесса на процессы нижнего уровня

Давайте разложим этот процесс на процессы нижнего уровня используя таблицу:

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

Процессы

1. Поступление заказа: Клиент отправляет заказ по почте, информация о заказе обрабатывается и сохраняется.
2. Проверка кредитного лимита: Информация о кредитном лимите клиента проверяется и хранится в базе данных клиентов.
3. Проверка наличия товара: Проверяется наличие товара на складе и информация сохраняется.
4. Уточнение заказов: В случае несоответствия заказа наличным товарам на складе, заказ считается недействительным и отправляется на уточнение в отдел поддержки клиентов.

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

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

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

С помощью чего рисовать диаграммы

Можно рисовать DFD-диаграммы, используя привычные вам инструменты. Для этого подойдут, например, всем известные MS Visio или Draw.io. Но для выстраивания системы с разными уровнями детализации потребуются специализированные программы для моделирования.

Существует множество редакторов для построения DFD-диаграмм. Самым популярным является Ramus. Этот продукт имеет бесплатную версию, доступен в сетевом и локальном вариантах. StarUML — проект с открытым кодом, ещё один ходовой инструмент для создания диаграммы потоков данных. Для командной работы можно использовать облачное решение Lucidchart.

Основные ошибки при разработке DFD-диаграмм

1. Отсутствие контекстной диаграммы

На первый взгляд диаграмма с одним процессным блоком и несколькими внешними сущностями может показаться лишней. Некоторые аналитики сразу переходят к детализированным DFD. Однако построение контекстной диаграммы необходимо! При помощи контекстной диаграммы мы определяем границы и так называемый scope — объем будущей проектируемой системы.

Контекстная диаграмма наглядно отображает, что находится вне системы и даёт ответ на главный вопрос, какой внутренний процесс мы будем детализировать на диаграммах нижних уровней. Это помогает избежать одну из популярных ошибок проектирования систем, когда хочется «объять необъятное».

2. Неименованные потоки данных

Ещё одна часто встречающаяся ошибка — отсутствие названий у входящих и исходящих потоков. Каждая стрелка на схеме должна иметь название.

3. Отсутствие процессов

Наличие процесса — один из основополагающих принципов моделирования DFD-диаграммы. Когда на диаграмме отражен только обмен данными между хранилищами без привязки к процессу, непонятно, каким образом и для чего хранилища передают данные друг другу.4. Отсутствие внешних сущностейВажно помнить, что DFD-диаграмма должна содержать одну или несколько внешних сущностей — источников входящих в процесс данных.5. Путаница между хранилищами и потоками данныхЭтой ошибки можно избежать, помня, что данные в DFD представлены в двух состояниях. Данные в состоянии покоя помещаются в хранилища, а данные в состоянии движения отражаются при помощи входящих и исходящих потоков.6. Стремление показать логику выполнения процессов.DFD – это нотация, предназначенная для моделирования структуры информационной системы, но не её логики. Поэтому будет ошибкой привязывать элементы DFD-диаграммы к временным шкалам или использовать условные операторы XOR, OR, AND.

7. Некорректное название элементов нотации

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

8. Отсутствие выходов у процессов

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

Источники для написания статьи

Действие Правило 1 “Глагол-объект” Правило 2 “Преобразующие действия” Правило 3 “Область действия” Внутренний процесс

Клиент начинает активность Триггер активности Нет Снаружи Нет

мы обрабатываем заказы, жалобы и платежи Отправка документов Нет Внутри Нет

Поступление заказа Обработка почты Да Внутри Да

мы подтверждаем кредитный лимит клиента Валидация кредитного лимита Да Внутри Да

мы подтверждаем наличие Подтверждения наличия товаров Да Внутри Да

Подтверждение заказа Аккумулирование подтвержденных заказов Нет Внутри Нет

и группировка по зонам отправки Группировка заказов Да Внутри Да

Передача на склад Передача подтвержденных заказов Нет Внутри Нет

Заказ выполнен Выполненный заказ ? Снаружи Нет

Как построить UML-диаграмму классов, выделив сущности предметной области. В чем разница между композицией и агрегацией, а также как показать ссылку на объект другого класса. Смотрим на примере интернет-магазина.

Как составить UML-диаграмму классов

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

Выделим класс Товар как абстракцию понятия доменной области. А жакет категории женская одежда от поставщика СуперШмот стоимостью 3 рубля будет конкретным представителем этого класса, т.е. его объектом. Другим объектом будут брюки категории женская одежда от того же поставщика СуперШмот стоимостью 5 рублей. Если эти объекты можно объединить в один комплект, например, брючный костюм категории женская одежда от поставщика СуперШмот стоимостью 7 рублей, между ними будет ассоциативная связь, о которой мы поговорим позже.

А пока отметим, что манипулировать объектами в ООП можно только после определения классов, к которым они принадлежат. Таким образом, класс представляет собой конструктор (шаблон), определяющий свойства и методы, которыми обладают все его объекты. Когда конкретный объект находится в памяти, занимая определенную именованную область памяти программы, и к нему можно обратиться по имени переменной, его называют экземпляром класса. Класс описывает поля и методы, которые будут доступны у его объекта. Объекты используются для моделирования конкретных сущностей реального мира. Можно сказать, что класс – это структура данных, т.е. комплексный тип данных, на который можно ссылаться, подобно тому, как атрибут поставщик в сущности Товар является ссылкой на сущность Поставщик.

Рассмотрим, как реализуются эти понятия ООП, написав на Python несколько классов, соответствующих исследуемому домену (интернет-магазин). Для этого сделаем сопоставление сущностей предметной области с классами в таблице.

Сущность домена Свойства Класс Поле Тип данных

поставщик (ссылка на поставщика) provider Provider

стоимость (вещественное число) price float

Заказ номер (целое число) number int

отметка времени (дата) timestamp date

клиент (ссылка на клиента) customer Customer

сумма (вещественное число) sum float

Поставщик название компании (строка) Provider company str

адрес электронной почты (строка) email str

физический адрес (строка) address str

UML для бизнес-аналитика: основы ООП и разработка моделейКод курсаBUMLБлижайшая дата курса11 марта, 2024Продолжительность8 ак.часовСтоимость обучения18 000 руб.

Визуализируем представленную таблицу виде UML-диаграммы классов, расставив кратности связей между классами:

Эта диаграмма создана с помощью следующего скрипта PlantUML:

Ассоциативные связи на диаграмме классов

В отличие от проектирования реляционной модели данных, понятие нормализации в UML не применимо и нет необходимости «развязать» связь много-ко-многим через отдельный класс, т.к. это реализуется в коде. Как именно это делается, разберем в следующей статье, когда перейдем к коду. А пока рассмотрим связи на этой UML-диаграмме классов. В этом примере все связи между классами являются ассоциативными и представленной в виде направленной ассоциации, когда один класс (первичный), использует другой класс (вторичный), в качестве своего поля или метода. В отличие от простой ассоциации, направленная имеет стрелку, указывающую направление связи между классами. Например, связь ассоциации от класса Order к классу Customer показывает, что каждый заказ соответствует конкретному покупателю, поскольку сделан от его имени.

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

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

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

Проверить свои знания UML вы можете прямо на нашем сайте, выполнив бесплатный интерактивный тест.

Открытый тест по UML: основы бизнес-анализа для начинающих

А научиться самостоятельно разрабатывать эти и другие UML-диаграммы вам поможет мой специализированный курс «UML для бизнес-аналитиков». Только практика на реальных примерах. После 8-часового интенсива вы сможете дополнять моделировать программные системы, чтобы наглядно объяснить разработчикам, из чего они должна состоять и что делать.