Data-flow diagram

В этой статье мы поговорим про основы бизнес-анализа и рассмотрим наиболее популярные на сегодня нотации моделирования UML, BPMN и EPC, а также покажем, почему структурные методы IDEF0, IDEF1 и DFD до сих пор актуальны. Читайте в этом материале, где и как использовать различные нотации бизнес-моделирования и что рекомендует руководство BABOK.

Взгляд BABOK на многообразие нотаций

Таким образом, на практике бизнес-аналитик работает с несколькими нотациями, чтоб описать бизнес-процессы предприятия или специфицировать требования к программному продукту. Разумеется, в реальности при этом используются не все вышеуказанные нотации бизнес-моделирования. Далее мы рассмотрим, какие диаграммы и для чего чаще всего применяются в практическом бизнес-анализе.

Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)Код курсаMODPБлижайшая дата курса13 июня, 2023Длительность обучения8 ак.часовСтоимость обучения15 000 руб.

Как описать системы и бизнес-процессы

Все многообразие нотаций бизнес-моделирования можно разделить на 2 категории:

• Структурные, которые показывают компонентный состав исследуемого объекта и взаимосвязи между его элементами. Например, UML-диаграммы классов, компонентов, кооперации, композитной структуры, развертывания, пакетов, объектов и профилей. Из нотаций стандарта IDEF к структурным относятся IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF.
• Динамические, которые показывают движение потоков данных или логику выполнения процессов. Например, DFD, EPC, BPMN, а также UML-диаграммы деятельности, состояний, вариантов использования и последовательностей.

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

• в задачах системного анализа и синтеза, таких как разработка совершенно нового технического продукта (ракета, автомобиль и пр.), преимущественно используются комплексные методологии семейства IDEF, позволяющие проектировать систему «сверху вниз» за счет функциональной декомпозиции – разбиения сложного объекта на более простые элементы с их последующим описанием;
• при разработке требований к программному обеспечению и документировании готового решения чаще всего применяется стандарт UML, позволяющий описать проектируемый продукт в объектно-ориентированных терминах. Для описания структуры базы данных используется ERD-нотация IDEF1x (Extended). А DFD-диаграмма наглядно продемонстрирует движение потоков данных между различными хранилищами (СУБД, файлы, бумажные и другие материальные носители) и процессами по их преобразованию. Подробнее о том, как разработать DFD-диаграмму, читайте здесь.

От структуры к логике: функциональная декомпозиция IDEF0-процесса в BPMN в системе Business Studio

В заключение отметим, что все рассмотренные и другие нотации бизнес-моделирования, в первую очередь, предназначены для аналитика и могут показаться сложными для руководителя или специалиста другой предметной области. В частности, руководство BABOK отмечает, что UML и BPMN-диаграммы в большинстве случаев кажутся стейкхолдерам слишком «техническими», что затрудняет восприятие информации. Поэтому при выборе нотации как инструмента моделирования следует помнить не только о цели (что хотим описать), но и о целевой аудитории (кому будем показывать). К примеру, схемы EPC, ярко и понятно описывающие алгоритм выполнения отдельных процессов, достаточно легко воспринимаются бизнес-пользователями. Что общего между EPC и BPMN нотациями, я рассказываю в этом материале.

Пример простой EPC-диаграммы без логических ветвлений в системе Business Studio

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

Освоить все рассмотренные нотации моделирования и их применение на практике вы сможете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

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

В своей самой первой статье (//infostart.ru/1c/articles/1305386/) я уже упоминала какие бывают методологии и нотации для описания бизнес-процессов. А также мы уже рассмотрели одну из нотаций – IDEF0 (//infostart.ru/1c/articles/1408200/). Но все больше и больше погружаясь в эту тему, я прихожу к выводу, что информации много, она плохо структурирована и существуют некоторые неточности. И выбрать для себя подходящий, удобный, понятный способ – достаточно трудно.

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

ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ И ТЕРМИНЫ

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

– это документирование процесса в свободной форме, например, простое текстовое описание пользовательских сценариев (Use Case).

• Это в любом случае задокументированный процесс (представленный на бумаге).
• Он может быть представлен в любом виде: текстовом, табличном, графическом.
• Без формальной логики и специальных обозначений и ограничений.

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

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

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

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

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

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

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

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

Или если более кратко – это способ достижения какой-либо цели, а способом будет нотация моделирования процессов.

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

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

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

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

1.        СТРУКТУРНОЕ МОДЕЛИРОВАНИЕ

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

1.1.        ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ

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

1.2.        ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ

(или моделирование проведения) – представление поведения системы во времени, описание поведения бизнес-процессов при различных внешних и внутренних условиях с анализом как динамических характеристик процессов, так и с распределением ресурсов.

1.3.        ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ

дает представление объектов предметной области, их свойств и отношений между ними.

2.      ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ МОДЕЛИРОВАНИЕ

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

3.      ИНТЕГРИРОВАННОЕ МОДЕЛИРОВАНИЕ

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

КРАТКОЕ ОПИСАНИЕ МЕТОДОЛОГИЙ И МЕТОДОВ

Методология структурного анализа и проектирования SADT (Structured analysis and design technique) – представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта (производимые им действия и связи между этими действиями) какой-либо предметной области. Разработана Дугласом Россом в 1969-1973 годах. Эта методология возникла под сильным влиянием PLEX, концепции клеточной модели человек-ориентированных функций Хори, общей теории систем технологии программирования и кибернетики. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения.

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

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

Элементы методологии SADT (синтаксис):

• (Activities) – совокупность действий;
• (Control) – определенные правила для выполнения действий;
• (Mechanism) – потребляемые информационные, человеческие и производственные ресурсы;
• (Input) – четко определенный вход;
• (Output) – четко определенный выход.

Самая распространенная нотация методологии SADT: IDEF0 (для функционального моделирования бизнес-процессов).

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

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

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

• Названия формулировать по следующее формуле:
  Название потока = Объект, представляющий поток + Статус объекта
• Использование краткой и лаконичной формулировки для повышения эффективности дальнейшей работы по оптимизации бизнес-процесса. 2-3 определяющих слова.

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

• (External Entity). Понимается материальный объект, являющийся источником или приемником информации. Пример: заказчики, поставщики, клиенты, склад, банк и др.
• (Process). Представляют собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом.
• (хранилище) данных (Data store). Предназначены для изображения неких абстрактных устройств для хранения информации, которую можно туда в любой момент времени поместить или извлечь, безотносительно к их конкретной физической реализации. Являются неким прообразом базы данных информационной системы организации.
• (Data flow). Определяют информацию, передаваемую через некоторое соединение (кабель, почтовая связь, курьер) от источника к приемнику. Изображаются линиями со стрелками, показывающими их направление. Каждому потоку данных присваивается имя, отражающее его содержание.

Нотации данной методологии DFD:

• Нотация Гайна -Сарсона (Gane / Sarson),
• Нотация Йордана – Де Марко (Yourdon / DeMarko).

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

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

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

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

Нотация, разработанная в данной методологии: IDEF3 (PFDD – Process Flow Description Diagrams), т.е. диаграмма описания последовательности этапов процесса, с помощью которой моделируется последовательность действий, реализуемых в рамках бизнес-процесса.

Архитектура интегрированных информационных систем ARIS (Architecture of Integrated Information Systems) — это архитектура, концепция, методология, инструментальная среда (тиражируемый программный продукт), нотация, а также это система взглядов на деятельность организации, которая позволяет проектировать, проводить анализ, оптимизацию и внедрение бизнес-процессов.

Методология ARIS был разработана Августом-Вильгельмом Шеером в 1990х, сегодня права принадлежат немецкой компании Software AG.

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

При этом каждая из этих точек зрения разделяется ещё на три подуровня:

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

Продукты линейки ARIS Design Platform включают в себя программы различной направленности, например, для моделирования архитектуры предприятия ARIS Business Architect и ARIS IT Architect или для имитационного моделирования и анализа бизнес-процессов – ARIS Business Simulator. Кроме того, доступна бесплатная программа ARIS Express с несколько урезанной функциональностью.

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

К числу наиболее значимых и практически используемых нотаций ARIS можно отнести:

• eEPC (extended Event-driven Process Chain) – расширенная нотация цепочки процесса, управляемого событиями;
• PDC (Process Chain Diagramme) –
• ERM (Entity-Relationship Model) – модель «сущность-связь» для описания структуры данных;
• UML (Unified Modeling Language) – унифицированный объектно-ориентированный язык моделирования;
• Нотация Value-added Chain Diagram – диаграмма цепочки процесса, добавляющего стоимость;
• Нотации Organizational Chart (организационная диаграмма), Functional Tree (дерево функций), Product Tree (дерево продуктов).

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

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

STD состоит из следующих объектов:

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

К самым распространенным нотациям и языкам моделирования STD можно отнести:

• Цветные сети Петри (CPN, Colored Petri Nets),
• IDEF3 (Object State Transition Description,OSTD) – описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния,
• Унифицированный язык имитационного моделирования (General Purpose Simulating System, GPSS),
• Язык визуального моделирования (SIMAN, SIMulation ANalysis).

(ERM, Entity-Relationship Model или ER-модель) – модель данных, позволяющая описывать концептуальные схемы предметной области.

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

В основе ER-модели лежат понятия:

• (Entity) – это объект, который может быть идентифицирован неким способом, отличающим его от других объектов. Примеры: конкретный человек, предприятие, событие и т.д.
• (Relationship) – это ассоциация, установленная между несколькими сущностями.
• (Attribute) описывают свойства всех членов данного набора сущностей.

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств ее визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (ERD, Entity-Relationship Diagram, ER-диаграмма).

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

Используемые нотации (графические модели):

• Нотация Питера Чена. Модель была предложена в 1976 году Питером Ченом, им же предложена и самая популярная графическая нотация для модели.
• Crow’s Foot. Нотация предложена Гордоном Эверестом (Gordon Everest) под названием Inverted Arrow («Перевернутая стрелка»), однако сейчас чаще называемая Crow’s Foot («Воронья лапка») или Fork («Вилка»).
• И другие нотации.

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

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

(С) из Интернета

В сущности, все модели неправильны, но некоторые полезны.

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

Потом была вторая часть (), в которой рассмотрели все семейство нотаций

А затем третья часть (), в которой была рассмотрена такая интересная отечественная нотация, как ДРАКОН, а также и нотация Йордана – Де Марко.

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

Краткое описание нотаций

О том, что такое BPMN, написано очень много. Нотация популярная, поэтому рассмотрим ее очень кратко.

Business Process Model , нотация и модель бизнес-процессов) – это система условных обозначений (нотация) и их описания в XML для моделирования бизнес-процессов. Разработана Business Process Management Initiative (BPMI.org) Object Management Group (OMG).

BPMN является частью двух составляющих:

• / Management) – это среда непосредственного моделирования бизнес-процессов или это управление бизнес-процессами, т.е. общая система, частью которой и является Business Process
• System) – это инструменты для исполнения созданных моделей бизнес-процессов. Инструментами могут быть такие программные продукты как: MS Visio, Business Studio, Bizagi, C, ELMA и др. Или это могут быть системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.

• предназначена для описания предметной области реального бизнеса.
• BPMN не описывает IT системы.
• Основное отличие данной нотации от других графических систем: в ней задействованы, как и программные системы, так и люди (клиенты, поставщики, сотрудники организации).
• В регламентированном описании бизнес-процессов в данной нотации используется около 10 значков без привязки к определенной методологии.

Для чего используется:

• Модели бизнес-процессов в нотации
  анализа и совершенствования бизнес-процессов;исполнения бизнес-процессов с помощью BPMS-систем;контроля за ходом выполнением бизнес-процессов;оптимизации, улучшения и реинжиниринга бизнес-процессов.
• анализа и совершенствования бизнес-процессов;
• исполнения бизнес-процессов с помощью BPMS-систем;
• контроля за ходом выполнением бизнес-процессов;
• оптимизации, улучшения и реинжиниринга бизнес-процессов.

• Не сложнее других нотаций (например: IDEF, DFD, EPC, UML);
• Понятна без предварительного обучения на базовом уровне;
• Хорошо подходит для коммуникаций «Бизнес-аналитик – Бизнес»;
• Подходит для описания не только бизнес-процессов, но и архитектуры предприятия (
• BPMN – это нотация, на базе которой можно создавать средства BPMN-моделирования;
• BPMN может моделировать исполняемые процессы, с высоким уровнем формализации;
• BPMN имеет унифицированный XML-формат хранения (экспорта-импорта) диаграмм.

• BPMN нотация имеет значительное количество понятий и терминов, которые нужно знать при ее использовании;
• Расширенная функциональность требует более глубокого и детального изучения для последующего использования;
• Необходимо знание основ бизнес-анализа: очень важна грамотная структура и четкая последовательность.
• BPMN предлагает только нотацию для описания бизнес-процессов, в нем нет нотации для описания организационной структуры, информационной модели, дерева целей и др. Это является ограничителем использования данной методологии.
• В целом BPMN-нотация содержит более 100 различных символов, поэтому часто случается так, что ВРМ-модель процесса сложна для прочтения как пользователям (Заказчикам), так и экспертам в области бизнес-моделирования.
• BPMN описывает только архитектуру процессов предприятия (архитектурный язык), и не годиться для описания информационной архитектуры предприятия (входящих, исходящих и внутренних документов, маршрутов и способов документооборота и т.д.), а значит, BPMN-описания практически бесполезны в случае внедрения (Enterprise Content Management).
• Язык BPMN непригоден для описания коммуникационной архитектуры предприятия: позиций и полномочий, просьб и приказов, распоряжений и обещаний.

Модель «Сущность-связь» (Entity Relationship Model, ER-model) – один из наиболее известных и получивших широкое распространение методов семантического моделирования. Разработана П. Ченом в 1976 г.

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

Диаграмма «Сущность-связь» (ERD, Entity-Relationship Diagram, ER-диаграмма) – это разновидность блок-схемы, где показано, как разные «сущности» (люди, объекты, концепции и так далее) связаны между собой внутри системы. ER-диаграммы чаще всего применяются для проектирования и отладки реляционных баз данных в сфере образования, исследования и разработки программного обеспечения и информационных систем для бизнеса. ER-диаграммы полагаются на стандартный набор символов, включая прямоугольники, ромбы, овалы и соединительные линии, для отображения сущностей, их атрибутов и связей. Эти диаграммы устроены по тому же принципу, что и грамматические структуры: сущности выполняют роль существительных, а связи – глаголов.

Диаграмма «Сущность-связь» (ER-диаграмма) в некотором смысле является абстрактным макетом базы данных, поэтому для ее моделирования был разработан ряд правил, которые облегчают переход от диаграмм к реляционным отношениям:

• Основной элемент: Сущность – это физическое представление логической группировки данных. Сущности представляют собой объекты, данные о которых корпорация заинтересована сохранять;
• Каждый правильный (сильный) тип сущности соответствует базовому реляционному отношению;
• Каждая бинарная связь типа «многие-ко-многим» также соответствует отдельному отношению, которое должно включать в себя два внешних ключа, ссылающихся на потенциальные ключи отношений, соответствующих сущностям – участникам связи;
• Связь типа «один-ко-многим» между сильными сущностями может быть представлена с помощью внешнего ключа и не требует отдельного отношения;
• Связь слабого объекта с сильным, от которого он зависит, является связью типа «многие-к-одному» и может быть представлена внешним ключом. В некоторых случаях, когда и сильная, и подчиняющаяся ей слабая сущности представлены одним реляционным отношением, внешний ключ может ссылаться на первичный ключ своего же отношения;
• Атрибуты сущностей приводятся к атрибутам отношений;
• В случае более чем бинарной связи (n-арной), обычно вводят ( + 1) отношение: по одному на каждую сущность и одну на связь.

• Используется при высокоуровневом (концептуальном) проектировании баз данных. С ее помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
• Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

• Основными преимуществами ER-диаграммы являются наглядность и возможность представлять произвольное количество данных с любым количеством свойств.
• На ER-диаграммах основано множество систем автоматизированного проектирования баз данных.
• Диаграмму «Сущность-связь» (ER-диаграмму) можно считать инструментом концептуального уровня.
• Диаграммы «Сущность-связь» (ER-диаграммы) являются развитой системой зависимости и ограничений целостности.
• ER-диаграммы являются способом проектирования данных и позволяют идентифицировать понятия предметной области и связи между ними, и дают легкий удобный графический интерфейс, который описывает структуру базы данных.

• ER-модель позволяет сделать «статический снимок» сущностей и связей между ними в данной предметной области.
• Для описания процессов информационного обмена между сущностями предметной области необходимо использовать другие методики (вместе или вместо ER моделирования), например,

Самые распространенные нотации (графические модели) ER-диаграмм:

• Классическая нотация Питера Чена (Peter Chen Notation);
• IE (Information Engineering) Мартина (James Martin) или «Вороньи лапки» (Crow’s Foot);
• IDEF1X (Integration Definition for Information Modeling);
• Нотация Ч. Бахмана;
• Нотация Ж.-Р. Абриаля (мин-макс);
• Диаграммы классов UML.

Нотации IDEF1 и IDEF1X и UML были рассмотрены ранее, поэтому в этой статье они уже описываться не будут.

Нотация Питера Чена

Оригинальная работа Питера Чена (Peter Chen) «The Entity Relationship Model – Toward A Unified View of Data» («Модель сущность-связь – Унифицированное представление данных») обычно цитируется как основополагающая для методологии ERD.

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

Нотация Баркера относится к нотации ERD. Разработана Ричардом Баркером, Ян Палмером, Гарри Эллисом и др. во время работы в британской консалтинговой фирме CACI около 1981 года. Обозначения были сформулированы Р. Баркером, когда он присоединился к Oracle, и точно определены в его книге «Entity Relationship Modeling», как часть серии книг по CASE методам. Эта нотация используется и сейчас в инструментах моделирования Oracle CASE. Нотация представляет собой разновидность стиля моделирования данных «Воронья лапка», который многие предпочитают оригинальному стилю П. Чена при моделировании ERD из-за большей удобочитаемости и эффективного использования пространства для рисования.

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

) информационного проектирования: нотация К. Финкельштейна (), нотация Дж. Мартина ( ) или «Вороньи лапки»

Родоначальником данной методологии (нотации) является Клайв Финкельштейн (Clive Finkelstein). Дальнейшее ее совершенствование связано с именами Джеймса Мартина (James Martin) и Чарльза Рихтера (Charles M. Richter). Так же можно встретить название – «Воронья лапка» (oot) («Куринная лапка») или «Вилка» (Fork), основу в данную нотацию предложена Гордоном Эверестом (Gordon Everest), и она также может носить название «Перевернутая стрелка» (Inverted Arrow). По графическому отображению и семантике элементов модели, нотация IE напоминает IDEF1X. Ее отличительной особенностью является указание мощности связей не в виде буквенно-цифрового обозначений, а с помощью графических элементов:

• o – ноль;
• – много (больше 0). Данный элемент иногда называют «Вороньей (куриной) лапкой» (Crow’s Foot).

В нотации IE сущность отображается в виде прямоугольника, содержащего его имя.

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

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

Нотация Ч. Бахмана

Одним из способов представления формализованного описания предметной области информационной системы в рамках модели «Сущность-связь» является использование техники специальных диаграмм, которая была предложена известным американским специалистом в области баз данных Ч. Бахманом.

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

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

Нотация Ж.-Р. Абриаля (мин-макс)

Нотация Жана-Раймона Абриаля разработанная в 1974 году. В тот же год введено и ее обозначение min, max), как часть семантической модели, которая конкурировала с моделью Чена. Однако, нотация П. Чена ассимилировала с нотацией (min, max), и ее можно концептуально использовать независимо от нотации Ж.-Р. Абриаля в качестве дополнения к нотации П. Чена.

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

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

Нотация Гейна – Сарсона (Gane / Sarson)

Основу методологии DFD составляет графический язык описания процессов. Авторами одной из первых графических нотаций DFD (1979 г.) стали Эд Йордан (Yourdon) и Том де Марко (DeMarko). В настоящее время наиболее распространенной является нотация Гейна – Сарсона (Gane – Sarson).

• Включает в себя такие элементы, как функциональный блок, отражающий функцию (операцию) моделируемой системы, в рамках которой идет преобразование данных, стрелки, показывающие движение данных между функциями, операциями, т. e. входящие и исходящие потоки, внешние субъекты, которые предоставляют и получают данные, хранилища данных, в которых данные собираются и хранятся.
• Главными элементами DFD-диаграммы являются функциональный блок и стрелки, то они на DFD-диаграмме должны присутствовать всегда. Хранилища данных и внешние субъекты могут быть представлены на диаграмме, а могут и отсутствовать.
• Внешними субъектами являются субъекты внешнего окружения организации (например, поставщики, клиенты), структурные подразделения, должностные лица, информационные системы и пр., от кого может поступать информация, которая используется для инициации описываемого бизнес-процесса.
• С помощью элемента «Хранилище данных» отражается место временного хранения промежуточных результатов обработки информации. Изображается хранилище данных в виде прямоугольника без одной стороны, в середине которого показывается его название.
• В нотацию был введен дополнительный объект, с помощью которого показываются места бизнес-процесса, в которых храниться информация либо математические ресурсы. Примеры таких мест – архив, в котором хранятся документы, база данных, в которой храниться информация, либо склад, на котором хранятся материальные ресурсы. Данный объект получил название – хранилище данных. На -схемах в нотации Гейна – Сарсона и Йордана – Де Марко также используются объекты, показывающие внешние субъекты, с которыми бизнес-процесс взаимодействует. Данные объекты называются внешними сущностями.

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

Итак, в целом мы рассмотрели все возможные нотации описания и моделирования бизнес-процессов. Кто знает еще какие нотации, которые было бы интересно посмотреть и понять?

Ask any professional athlete or business executive how they became successful, and they’ll tell you they mastered a process. By figuring out which of their habits led to success and which didn’t, they improved their efficiency, effectiveness, and productivity at work.

But implementing a process into a business, department, or even a team is a completely different animal than honing your own personal process. With so many moving parts, how do you track each aspect of your business’ process and how do you refine it?

Data flow diagrams provide a straightforward, efficient way for organizations to understand, perfect, and implement new processes or systems. They’re visual representations of your process or system, so they make it easy to understand and prune.

Before we dive into how data flow diagrams can help refine any of your business’ systems or processes, let’s go over what it exactly is.

What is a data flow diagram (DFD)?

A data flow diagram (DFD) is a visual representation of the information flow through a process or system. DFDs help you better understand process or system operation to discover potential problems, improve efficiency, and develop better processes. They range from simple overviews to complex, granular displays of a process or system.

There are two types of DFDs — logical and physical. Logical diagrams display the theoretical process of moving information through a system, like where the data comes from, where it goes, how it changes, and where it ends up.

Physical diagrams show you the practical process of moving information through a system, like how your system’s specific software, hardware, files, employees, and customers influences its flow of information.

You can either use logical or physical diagrams to describe the same flow of information or you can use them in conjunction to understand a process or system on a more granular level. But, before you can use a DFD to understand your system or process’ flow of information, you need to know the standard notations or symbols used to describe it.

Data Flow Diagram Symbols

Data Flow Diagram symbols are standardized notations, like rectangles, circles, arrows, and short-text labels, that describe a system or process’ data flow direction, data inputs, data outputs, data storage points, and its various sub-processes.

There are four common methods of notation used in DFDs: Yourdon & De Marco, Gene & Sarson, SSADM and Unified. All use the same labels and similar shapes to represent the four main elements of a DFD — external entity, process, data store, and data flow.

External Entity

An external entity, which are also known as terminators, sources, sinks, or actors, are an outside system or process that sends or receives data to and from the diagrammed system. They’re either the sources or destinations of information, so they’re usually placed on the diagram’s edges. External entity symbols are similar across models except for Unified, which uses a stick-figure drawing instead of a rectangle, circle, or square.

Process

Process is a procedure that manipulates the data and its flow by taking incoming data, changing it, and producing an output with it. A process can do this by performing computations and using logic to sort the data, or change its flow of direction. Processes usually start from the top left of the DFD and finish on the bottom right of the diagram.

Data Store

Data stores hold information for later use, like a file of documents that’s waiting to be processed. Data inputs flow through a process and then through a data store while data outputs flow out of a data store and then through a process.

Data flow is the path the system’s information takes from external entities through processes and data stores. With arrows and succinct labels, the DFD can show you the direction of the data flow.

1. Each process should have at least one input and one output.

2. Each data store should have at least one data flow in and data flow out.

3. A system’s stored data must go through a process.

4. All processes in a DFD must link to another process or data store.

Levels of Data Flow Diagrams

DFDs can range from simple overviews to complex, granular representations of a system or process with multiple levels, starting with level 0. The most common and intuitive DFDs are level 0 DFDs, also called context diagrams. They’re digestible, high-level overviews of the flow of information through a system or process, so almost anyone can understand it.

Context Diagram

This DFD level focuses on high-level system processes or functions and the data sources that flow to or from them. Level 0 diagrams are designed to be simple, straightforward overviews of a process or system.

Process Decomposition

While level 1 DFDs are still broad overviews of a system or process, they’re also more detailed — they break down the system’s single process node into subprocesses.

Deeper Dives

The next level of DFDs dive even deeper into detail by breaking down each level 1 process into granular subprocesses.

Increasing Complexity

Level 3 and higher-numbered DFDs are uncommon. This is largely due to the amount of detail required, which defeats its original purpose of being easy to understand.

Data Flow Diagram Examples

Professionals in various industries, like software engineering, IT, ecommerce, and product management & design, can use DFDs to better understand, refine, or implement a new system or process.

But what does a data flow diagram look like in practice — and how does it help your business? Here are three examples to help contextualize DFD impact.

Level 0 DFD

This Level 0 DFD provides a contextual map of a securities trading platform. Data flows in one direction from the customer service assistant and the broker to the platform, and in two directions from customers to the platform and back again.

Level 1 DFD

This Level 1 DFD breaks down the customer process in more detail, expanding it to include account creation, cash withdrawals, and eventual securities transactions.

Level 2 DFD

This Level 2 DFD decomposes the “Place Order” process to contextualize the steps required to place an order — either by a customer or by a broker. It even accounts for a third-party stock exchange center where transaction details are forwarded after an order is placed.

How to Make a Data Flow Diagram

• Select a system or process.
• Categorize related business activities.
• Draw a Context DFD.
• Check your work.
• Create child diagrams.
• Expand processes into Level 1 DFDs.
• Repeat as needed.

Select a system or process.

Begin by selecting a specific system or process you want to analyze. While any system or process can be turned into a DFD, the larger the process the more complicated the diagram and the more difficult it will be to contextualize. Wherever possible, start with a small function or process you’re looking to improve.

Categorize related business activities.

Next, categorize all activities related to this process into external entities, data flows, processes, and data stores.

Consider a restaurant food ordering system. Customers are external entities, the food ordering system is a process, and the interaction between customers and the system (which goes in both directions) is the flow.

Also worth noting? The ordering system doubles as a data store, so for an SSADA model, this means drawing it as a rectangle with rounded corners with two horizontal lines inside to represent its dual function.

Draw a Context DFD.

Now it’s time to start drawing. DFDs can be created by hand, using free templates available online, or via browser extensions.

Begin with a simple, Level 0 DFD: Start with your process or system, then map all basic connections and flows.

Check your work.

Before diving into more complex DFDs, check the work you’ve already done to make sure it’s accurate and complete. If you’ve missed (or added) a process, entity, or flow, your next-level DFDs may not make sense and you may be forced to start over.

Create child diagrams.

For each process or system described in your Level 0 DFD, create a new child diagram with its own entities and flows. Eventually, you can use these child diagrams to connect processes together.

Expand processes into Level 1 DFDs.

Using your child diagrams, you should map more in-depth connections between each process. In the case of our restaurant example, this could mean digging deeper into the food ordering system and its connection to suppliers, managers, customers, and kitchen staff.

Repeat as needed.

Each process — no matter how large or small — can be reimagined as a Level 0 context diagram and the cycle can begin again. Repeat these steps as needed to create as many DFDs as required, or break processes down further to develop Level 2, 3, etc. DFDs.