Какой метод моделирования бизнес процессов использует язык объектного моделирования uml

Статья написана на основе лекций «Моделирование и анализ бизнес-процессов» профессора Томского государственного университета систем управления и радиоэлектроники, Силич Марии Петровны.

Классификация моделей

Понятие модели

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

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

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

Модель внешнего вида часов

Структурная схема часов

Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).

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

Классификация моделей

Познавательные (объяснительные) модели отражают уже существующие объекты.

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

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

Материальные модели построены из реальных объектов.
Абстрактные модели — это идеальные конструкции, выполненные средствами мышления, сознания.

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

Детерминированные модели отражают процессы и явления, не подверженные случайностям.
Стохастические – отражают случайные процессы, описываемые вероятностными характеристиками и статистическими закономерностями.

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

Языки описания моделей

Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.

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

Требования к нотации:

• простота — простой знак предпочтительнее сложного;
• наглядность — хотя бы отдаленное сходство с оригиналом;
• индивидуальность — достаточное отличие от других обозначений;
• однозначность — нельзя обозначать одним символом различные объекты;
• определенность — четкие правила использования модели;
• учет устоявшихся традиций.

Содержание модели бизнеса

В модели бизнеса отражают:

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

Методы моделирования бизнеса

Структурные методы

Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.

Принципы структурного подхода:

• «разделяй и властвуй» — разбиение сложных проблем на множество меньших задач, легких для понимания и решения;
• иерархическое упорядочивание – организация составных частей проблемы в иерархические древовидные структуры.

Две группы методов: моделирующие функциональную структуру и структуру данных

Наибольшее распространение получили методологии:

• IDEF0 – функциональные модели, основанные на методе SADT;
• IDEF1X – диаграммы данных «сущность-связь» (ERD);
• IDEF3 — диаграммы потоков работ (Work Flow Diagrams);
• DFD — диаграммы потоков данных (Data Flow Diagrams).

Методы объектно-ориентированного моделирования

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

Наиболее известные методы:

• Booch’93 Г. Буча,
• OMT Дж. Румбаха
• OOSE А. Джекобсона
• UML (Unified Modeling Language) – на основе Booch’93, OMT, OOSE

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

Методы имитационного моделирования

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

Наиболее распространенные методы:

• сети Петри и раскрашенные сети Петри (CPN, Colored Petri Nets);
• GPSS (General Purpose Simulating System) – унифицированный язык имитационного моделирования;
• SIMAN (SIMulation ANalysis) – язык визуального моделирования.

Интегрированные методы

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

• ARIS (Architecture of Integrated Information System) позволяет отражать в единой интегрированной модели: оргструктуры, функции, данные, процессы. Использует множество типов моделей.
• G2 — методология создания динамических интеллектуальных систем позволяет моделировать процессы с использованием знаний эксперта.
• BRM (Business Rules Management) – методология управления бизнес-правилами.

Структурные методологии

Методология IDEF0

Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.
IDEF0-модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).

Основные элементы модели:

• Функциональный блок (Activity) – преобразование (активность);
• Выходы (Output) – результат преобразования;
• Входы (Input) — объекты, которые преобразуются в Выходы;
• Управление (Control) — информация, как происходит преобразование;
• Механизм (Mechanism) – объекты, осуществляющие преобразование.

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

Таким образом, IDEF0-модель состоит из набора иерархически связанных диаграмм
На диаграмме блоки соединяются дугами: выходные дуги одних блоков могут являться входами (управлением, механизмом) других.
Дуги с одним свободным концом имеют источник или получатель вне диаграммы. Для обозначения внешних дуг используются буквы:

• I (Input),
• C (Control),
• O (Output) и
• M (Mechanism).

Типы связей между блоками:
Выход-вход

Выход-управление

Выход-механизм

Обратная связь по управлению

Обратная связь по входу

Методология IDEF3

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

Выделяют четыре элемента IDEF3-модели:
Единица работы — отображают действия, процессы, события, этапы выполнения работ. Единица работы может иметь только один вход и один выход

Ссылки (Referents):
необходимые элементы для выполнения процесса (сырье, материалы);
результат процесса (изделие);
активаторы процесса (клиент, поставщик).

Связи (Links), которые бывают двух типов:
передают действия от одной единицы работ к другой

соединяют ссылку с единицей работ (активируют единицу работ)

Перекрестки (Junctions) – элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса.
Бывают двух видов:
перекрестки слияния – Fan-in

перекрестки ветвления – Fan-out

Типы перекрестков

Асинхронное И (Asynchronous AND)
выходной процесс запустится, если завершились все входные процессы

после завершения входного процесса запустятся все выходные процессы

Синхронное И (Synchronous AND)
выходной процесс запустится, если завершились одновременно все входные процессы

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

Асинхронное ИЛИ (Asynchronous OR)
выходной процесс запустится, если завершится один или несколько входных процессов

после завершения входного процесса запустятся один или несколько выходных процессов

Синхронное ИЛИ (Synchronous OR)
выходной процесс запустится, если завершились один или несколько входных процессов, причем завершились одновременно

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

Исключающее ИЛИ (XOR, Exclusive OR)
выходной процесс запустится, если завершился только один входной процесс

после завершения входного процесса запустится только один выходной процесс

Пример IDEF3

Правила создания перекрестков

1. Каждому перекрестку слияния должен предшествовать перекресток ветвления.
2. Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
3. Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
5. Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.

Правило относительно единиц работ

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

Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.

Методология DFD

Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации.
Используются две нотации: Йордана и Гейна-Сарсона

Типы структурных элементов (в нотации Гейна-Сарсона):
1. Процессы (функции, операции, действия), которые обрабатывают и изменяют информацию. Процессы показывают, каким образом входные потоки данных преобразуются в выходные

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

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

4. Внешние сущности — определяют внешние элементы, которые участвуют в процессе обмена информацией с системой. Внешние сущности изображают входы в систему (источники информации) и/или выходы из системы (приемники информации). Примеры: заказчик, персонал, поставщик, клиент, склад, банк

Пример:

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

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

Прецедентная модель бизнеса

Отражает основные бизнес-процессы, их взаимодействие с окружением.
Начинается с построения внешней диаграммы (вариантов использования — Use Case Diagram), показывающей, как бизнес виден извне

Актор (действующее лицо, business actor) — субъект окружения бизнеса. Примеры акторов: Клиент, Покупатель, Поставщик, Партнер, Акционер, Заказчик.

Прецедент (вариант использования, business use case) — относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному актору .
Примеры прецедентов: Производство продукта Продажа продукта, Сервисное обслуживание, Разработка продукта, Маркетинг и сбыт.

Экземпляр (реализация) прецедента – конкретный вариант хода событий класс прецедентов — обобщенный прецедент.

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

Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate).
Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки)
Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend).

Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.

В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов

Поток событий прецедента

Поток событий — описание прецедентов последовательностью шагов

Поток событий прецедента «Продажа продукта»:

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

Диаграмма деятельности (Activity Diagram)

Элементы диаграммы деятельности

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

Структурирование прецедентов

Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
1. Выделение фрагментов
Если из описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент. Между выделенным прецедентом и базовым устанавливается отношения включения (include).
Иногда используют отношение расширения (extend). Оно устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.

2. Обобщение
Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский). Между каждым из частных прецедентов и родительским устанавливается отношение обобщения (generali-zation).

Объектная модель бизнес-процесса

Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют.
Классы объектов модели бизнеса:
активные — исполнители процессов (стереотип business worker), например, Продавец, Изготовитель, Разработчик;

пассивные — сущности (стереотип business entity), например, Продукт, Заказ, Счет.

Иногда среди активных выделяют:
интерфейсные (стереотип Boundary) – активные объекты, взаимодействующие с окружением, т.е. с акторами. Примеры – Продавец, Регистратор, Секретарь..
управляющие (стереотип Control) – активные объекты, участвующие в выполнении процессов, но не имеющие контакта с окружением. Примеры – Разработчик продукции, Изготовитель, Менеджер проекта..

Классы и объекты

Класс – некоторый тип объектов (множество похожих объектов),
Экземпляр – конкретный объект (представитель класса).

Объекты имеют:
имя (через двоеточие может быть указано имя класса)
свойства — описываются с помощью атрибутов
поведение — представляется с помощью операций

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

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

Динамическая диаграмма взаимодействия

Прецедент «Продажа заказного продукта»:
Продавец получает заявку клиента
Продавец формирует заказ и передает его Изготовителю продукта.
Изготовитель изготавливает продукт.
Изготовитель отправляет продукт на Склад и сообщает о готовности Продавцу.
Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату.
Продавец сообщает Отправителю адрес клиента и заказывает транспорт.
Отправитель получает продукт со склада и доставляет его клиенту.

Элементы диаграммы последовательности

В верхней части диаграммы – активные объекты (и акторы) в виде прямоугольника («человечка»), от которого вниз проведена «линия жизни».
Сообщение (message) – отрезок горизонтальной линии со стрелкой, проведенный от линии жизни объекта (актора), посылающего сообщение, до линии жизни объекта (актора), получающего сообщение.

Отношение сообщения моделирует материальный или информационный поток.
Прием сообщений инициирует выполнение некоторого действия получателем

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

Статическая диаграмма взаимодействия

Диаграмма кооперации (Collaboration Diagram)

Диаграмма классов

Диаграмма классов (Class diagram) используется для отображения устойчивых связей между классами объектов
Диаграмма классов для прецедента «Продажа продукта»

Для структурирования классов используются отношения обобщения и включения

Описание объектов

Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).

Интегрированная методология ARIS

Методология ARIS (Architecture of Integrated Information System) разработана в 1990-х годах профессором А.-В. Шеером

Для каждого из этих представлений можно построить несколько типов моделей (в ARIS 5.0 общее количество типов диаграмм — 130)

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

• организационные модели — структура организации (иерархия подразделений и должностей);
• функциональные модели — иерархия функций (целей), выполняемых в организации;
• информационные модели — структура информации, необходимой для реализации функций системы;
• модели процессов/управления — комплексный взгляд на реализацию деловых процессов в рамках системы

Организационная схема

К организационным моделям относится Организационная схема (Organizational chat).
Основные типы объектов этой модели:

Модель строится иерархически — от верхнего уровня структуры к нижнему.
Низшим уровнем является описание подразделений на уровне должностей — штатных единиц, занимаемых конкретными сотрудниками.

Дерево функций

К функциональным моделям относится Дерево функций (Function Tree).

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

Событийная цепочка процесса

К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)

Основные типы объектов:

Элементы диаграммы eEPC

• Функция – некоторое (шаг процесса). С функцией могут быть связаны: исполнители, входные и выходные документы, программное обеспечение и т.д.
• Событие — какое-либо завершенное состояние объекта, которое влияет на дальнейший ход процесса. С одной стороны события являются стимулом к выполнению функций, с другой – их результатом.
• Логические операторы (И, ИЛИ, XOR) показывают разветвления в потоке процесса.

Примеры:

Интеграция моделей

Взаимосвязь моделей ARIS обеспечивается с помощью двух механизмов: интеграции и детализации
1. Механизм интеграции
Благодаря хранению объектов в едином репозитории (специальной базе данных).
При создании нового объекта в репозитарии появляется отдельная запись, задающая описание объекта.
Объект можно скопировать из одной модели и вставить в другую с помощью команд Copy/Paste.

Детализация моделей

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

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

Инструментальные средства

Возможности инструментальных средств

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

Использованная литература

1. Национальный исследовательский Томский политехнический университет. Томск. Силич М.П. 2016. 75 с. Презентация к лекции.

UML (Unified Modeling Language — унифицированный язык моделирования) — это тип нотации, используемый для визуализации, определения, конструирования и документирования компонентов программных и непрограммных систем.

Краткая история

История создания языка программирования берет свое начало в 1967 году при появлении языка SimulaF67: он существенно отличается от современного, однако задает базовые идеи, которые существуют и сегодня. Официальное создание UML началось в 1994 году и первая версия 0.8 получила статус пробной.

В 1995 году концепция была расширена и дополнена языком OOSE. Таким образом повилась версия 0.9, с которой началось полноценное развитие UML, имеющего стратегическое значение для бизнеса.

Первая официальная всемирная версия UML появилась в январе 1997 года. Язык UML стал основой моделирования для различных классов систем и их программного обеспечения. Нотация начала применять объектно-ориентированные методы, обрела концептуальный, логический и физический уровни моделирования систем.

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

Плюсы и минусы методологии

Среди ключевых преимуществ модели выделим следующие характеристики:

1. UML — это объектно-ориентированный язык, поэтому методы, с помощью которых описываются результаты анализа и проектирования являются семантически идентичными к методам программирования на ключевых ОО-языках, используемых в современных технологиях.
2. С помощью UML можно описать ситуацию или ключевую задачу с различных точек зрения и аспектов поведения системы.
3. UML диаграммы простые в восприятии: прочитать схему и ознакомится с ее синтаксисом сможет даже работник, не имеющих специальных знаний в области программирования и постройки бизнес-моделей (речь идет о стандартных схемах с 20-40 условными обозначениями).
4. UML минимизирует процент возможных ошибок при создании бизнес-процесса. Например, она исключает несогласованность параметров дополнительных программ или изменение основных атрибутов.
5. Любой этап бизнес-процеса может быть использован повторно в уже существующем или новом проекте организации.
6. UML можно применять не только для решения вопросов программной инженерии, но и для введения собственных текстовых и графических стереотипов.
7. В отличие от аналогичных нотаций, UML стремительно развивается и получает широкое распространение в построении моделей различных сферах бизнеса.

Как и другие нотации, UML имеет недостатки:

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

Типы сущностей

Нотации UML — это ключевые элементы для моделирования и визуализации бизнес-процессов. Если цель изображена некорректно, выбраны неправильные и малоэффективные обозначения, то модель считается бесполезной и не содержательной.

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

Структурные

Структурные сущности — это имена существительные, представленные в статистической части модели: они соответствуют как концептуальным, так и физическим элементам системы. Среди основных структурных элементов выделают:

• Классы используются для представления объектов (требуют ответственных и имеют конкретные свойства). Диаграмма визуально разделена на четыре части: верхняя позиция (1) называет класс, вторая — отображает его атрибуты и основные инструменты, третья — детализирует операции и процессы, конечная — содержит дополнительную информацию и является необязательной.
• Объекты (экземпляр класса) — процессы, являющиеся фактической реализацией класса. Графически изображены как предшественники, единственное отличие в том, что название дополнительно подчеркивается.
• Интерфейсы используются для описания функционала по соответствующим требованиям. Интерфейс является своеобразным шаблоном, в котором расписаны этапы бизнес-процессов без их фактической реализации. На схеме отображается кружком с соответствующим названием, указанным под обозначением.
• Сотрудничество — это условное обозначение ответственности: отвечает за распределение задач в группе и назначении ответственных, чьи имена будут вписаны внутри круга с пунктирным контуром.
• Случаи использования подразумевают ситуации, для которых применимы функциональные возможности высокого уровня системы. Графически вариант использования прописывается под фигурой с обозначением сотрудничества.
• Актер — внутренняя или внешняя сущность, которая используется для описания внутренних или внешних задач бизнес-процесса. Актер взаимодействует с системой и может быть обозначен на любом этапе схемы.
• Нотация начального состояния — отображает начало бизнес-процесса; конечная государственная запись — конец процесса и соответственно результат.
• Компонент — представляет объект системы, для которого была создана диаграмма UML. Графически отображается в виде прямоугольника, в котором указан исполнитель и название задачи.
• Нотация активного класса — представляет параллельность задач в системе и изображается в формате квадрата, разделенного на три блока: 1 — название класса, 2 — параллельные требования системы, требующие описания, 3 — операции и процессы.
• Узел обозначает физический компонент системы (использование сети, серверов или оборудования). На схеме представлен в виде куба, в котором указано название узла и исполнитель.

Поведенческие

К данном классу относятся динамические и составляющее модели UML — глаголы, описывающие поведение модели во времени и пространстве. Рассмотрим основные поведенческие сущности:

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

Группирующие

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

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

Аннотационные

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

Рассмотрим основные типы аннотационных сущностей:

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

Виды диаграмм, используемых в Unified Modeling Language

В языке UML представлено 12 диаграмм, обуславливающих статистическую, поведенческую и физическую деятельность компонентов систем. Рассмотрим доступные и актуальные в современных бизнес-процессах диаграммы:

1. Диаграмма прецедентов (Use-case diagram). В основе — Actor (исполнитель), который устанавливает логические связи между ролями и прецедентами и Use case (сам прецедент), демонстрирующий какой именно процесс исполняется.
2. Диаграмма классов (Class diagram) представляет собой набор статических и декларативных элементов модели, имеющие общие атрибуты и операции. Диаграмма имеет наиболее полное и развернутое описание связей в программном коде, функциональности и информации об отдельных классах.
3. Диаграмма активностей (Activity diagram) отображает динамические аспекты поведения и общее представление о работе системы в формате блок-схемы. Диаграмма необходима для описания бизнес-процессов, взаимодействия нескольких систем, логики процедур и потоков работ, особенно при переходе от одной деятельности к другой.
4. Диаграмма последовательности (Sequence diagram) описывает поведенческие аспекты системы, вид сообщений и уточняет прецедентов. Необходима для отображения взаимодействия объектов в динамике и во времени, подразумевает обмен сообщениями в рамках конкретного сценария.
5. Диаграмма развёртывания (Deployment diagram) отображает графическое представление инфраструктуры, а именно распределение компонентов системы по узлам и маршруты их соединений. Диаграмма организовывает компоненты и решает второстепенные задачи, связанные с определенным аспектом бизнес-процесса.

Упрощение моделирования с помощью программного обеспечения

Для упрощения моделирования доступны разнообразные инструменты моделирования UML, а также разработанные ПО. Среди всех доступных возможностей, следует выделить IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner и Dia. Они обладают хорошим функционалом и широким спектром инструментов для построения диаграмм и рациональным распределением задач между исполнителями.

Вне зависимости от выбранного ПО, необходимо учитывать, что язык UML основывается на общих принципах моделирования, которыми не следует пренебрегать:

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

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

UML (Unified Modeling Language) — стандартный язык для описания, визуализации, проектирования и документации элементов информационных систем. Нотация принадлежит консорциуму OMG (Object Management Group), который разрабатывает ее с 1997 года. OMG также разрабатывает BPMN 2.0 — нотацию для проектирования бизнес-процессов.

Диаграммы UML отражают какой-то один аспектов информационной системы, а не систему в целом. Например, диаграмма вариантов использования (use-case model) показывают систему с точки зрения взаимодействия с конечным пользователем. За счет комбинации различных диаграмм можно достичь целостного взгляда на модель проектируемой системы, что крайне полезно при разработке.

Принципы нотации UML

Как и любая нотация, UML служит средством коммуникации между разработчиками системы.

Задачи UML

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

Цель UML — создать точные, исчерпывающие и предельно понятные модели информационных систем.

Особенности UML

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

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

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

В UML объекты содержат данные и методы их контроля. Данные описывают состояние объекта. Классы описывают объекты и образуют иерархию, которая отражает реально существующую систему. Объекты — это сущности реального мира, и UML использует для их отображения такие методы, как абстракция, инкапсуляция, наследование и полиморфизм. Таким образом диаграммы UML по сути являются объектно-ориентированным представлением.

Теперь легко понять базовые принцип работы с нотацией UML:

1. Установить объект и все его функции. Совокупность функции объектов определяют цели проектируемой системы.
2. Соотнести объекты друг с другом с учетом всех задуманных связей в рамках целого.
3. Реализовать полученную модель с помощью языков программирования Java, С++ и др.

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

Типы UML диаграмм

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

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

Модель использования в нотации UML (Use-case model)

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

Диаграммы прецедентов

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

Для чего используют диаграммы прецедентов? Чтобы исключить дублирование функциональных возможностей системы в рамках прецедента. Например, на схеме видно, что форму регистрации заполняет как студент, так и преподаватель. Глядя на схему, разработчик понимает, что определенные элементы интерфейса и кода можно использовать повторно. Это экономит время и ресурсы при разработке.

Диаграмма деятельности (активности)

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

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

Диаграмма последовательности

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

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

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

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

BPMN 2.0 — интуитивно-понятная нотация для бизнеса и ИТ

Немного скажем о нотации BPMN 2.0. Противопоставлять UML и BPMN 2.0 не очень правильно, поскольку эти две нотации решают разные задачи, и к тому же принадлежат одному консорциуму.

• UML — инструмент проектирования систем, чаще всего информационных
• BPMN 2.0 — инструмент проектирования бизнес-процессов.

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

Comindware Business Application Platform использует для моделирования процессов именно нотацию BPMN 2.0, что упрощает создание бизнес-ориентированных решений. Платформа использует простые Low-code методы разработки, которые можно освоить за 2 дня, не владея навыками программирования. Метод разработки, предложенный платформой, позволяет проектировать системы на основе диаграмм BPMN.

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.