Файл: Применение процессного подхода для оптимизации бизнес-процессов.pdf

2.2. Моделирование в нотации BPMN

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

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

Нотация поддерживает лишь определенный набор концепций, необходимый для моделирования БП.

Моделирование иных аспектов, кромеБП, находится вне зоны действия BPMN.

К примеру, моделирование следующих аспектов не будет описываться в BPMN[2]:

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

– Элементы – моделирование в BPMN выполняется посредством диаграмм с незначительным числом графических элементов. Данный факт помогает пользователям понимать логику процесса.

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

– объекты потока управления, а именно действия, логические операторы, события;

– соединяющие объекты: поток сообщений, ассоциации, поток управления.

– роли: дорожки и пулы;

– артефакты: группы. текстовые аннотации, данные.

Объекты потока управления могут быть разделены на 3 основных типа [7]:

• cобытия;
• действия;
• логические операторы.

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

– промежуточные;

– начальные;

– завершающие.

Начиная с BPMN 1.1 различают события обработки и генерации. Ниже представлена категоризация событий по типам (рисунки 5, 6).

Рисунок 5 – Основные категории событий

---

Рисунок 6 – Вспомогательные категории событий

Простые события – нетипизированные события, использующиеся, чаще всего, для указания на начало или окончание БП.

События-сообщения показывают получение или отправку сообщений в процессе выполнения БП.

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

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

События-отмены реагируют на отмену транзакций.

События-компенсации инициируют компенсацию и выполняют действия для компенсации.

События-условия позволяют интегрировать разные бизнес-правила в БП.

События-сигналы выполняют рассылку и принимают сигналы с нескольких процессов.

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

Составные события моделирует генерацию или моделирование одного события с множества.

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

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

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

Такие действия различаются заданиями и подпроцессами. Графическое изображение свёрнутого подпроцесса также снабжено знаком плюс около нижней границы прямоугольника (рисунок 7).

Рисунок 7 –Типы действий

Задание – это единица работы или элементарное действие в БП.

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

2.3. Моделирование в нотации UML

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

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

---

Унифицированный язык для объектно-ориентированного моделирования UML явился методом достижения компромисса между такими подходами [6].

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

Мощный толчок для разработки этого направления ИТ дало распространение ООП в конце 1980-х годов.

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

UML представляет собой объектно-ориентированный язык для моделирования, обладающий такими основными характеристиками [9]:

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

– содержит механизмы расширения или специализации базовых концепций для языка моделирования.

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

– строить модели на основании средств ядра, без применения механизмов расширения большинства типовых приложений;

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

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

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

Ниже приводится назначение основных перечисленных диаграмм и моделей.

Диаграммы прецедентов –обобщенная модель функционирования систем в окружающей среде [2].

Диаграммы видов деятельности – это модель бизнес-процесса и поведения системы в границах прецедентов.

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

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

---

Диаграммы классов – это логическая модель для базовой структуры системы. Они отражают ее статическую структуру и связи между элементами.

Диаграммы базы данных (БД)– это модель структуры БД, отображает столбцы, таблицы, ограничения и т.д.

Диаграммы компонентов – модель иерархии подсистем. Они отражают физическое размещение БД, приложений или интерфейсов системы.

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

На рисунке 8 показаны отношения между разыми видами диаграмм UML.

Стрелки можно интерпретировать как отношения«является источником входных данных для...» (к примеру, диаграмма прецедентов является источником для диаграмм видов деятельности).

Рисунок 8 – Взаимосвязь между UML-диаграммами

Модель бизнес-прецедентов описывает БП с точки зрения внешнего пользователя, то есть отражает взгляд на работу организации из вне.

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

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

Прецедент – это законченная последовательность действий.

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

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

Ассоциация – это связь между элементами модели. На диаграмме представлена линией.

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

На диаграмме представляется с помощью стрелки.

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

На рисунке 9 представлена общая модель деятельности центра в виде диаграммы прецедентов. Прецедент "Обслуживание пациента" реализуется через множество других, более ограниченных прецедентов (рисунок 10), отражающих детализацию представления функционирования центра.

---

Рисунок 9 – Общая диаграмма деятельности медицинского центра для обслуживания пациентов

Рисунок 10 – Модель бизнес-прецедентов для составляющих обслуживание пациента

Непосредственное выполнение прецедента описывается при помощи диаграмм видов деятельности. Они отображают исполнителей и всю последовательность выполнения соответствующих БП (рисунок 11).

Рисунок 11 –Диаграмма видов деятельности прецедента «Оказание медицинской помощи»

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

При написании второй части работы рассмотрены основные методологии и подходы для выполнения моделирования БП:

– нотация IDEF;

– нотация BPMN;

– нотация UML.

Заключение

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

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

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

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

Основу многих современных нотаций моделирования бизнес-процессов составляет методология BPMN и алгоритмические языки для разработки ПО.

С помощью методологии IDEF можно эффективно реализовать и анализировать модели для деятельности широкого спектра самых сложных систем в разных разрезах.

---