Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Моделирование бизнес-процессов. Учебное пособие.pdf
Пример построенной диаграммы в нотации EPC представлен на рис. 3.3.
Рис. 3.3. Пример реализованного бизнес-процесса в нотации EPC
Широкое применение нотация EPC получила не только благодаря
простоте и доступности. Данная методология имеет ряд преимуществ:
• возможность учитывать все необходимые организационные эле-
менты на одной диаграмме (такой возможности нет во многих нотациях);
• возможность применяться на разных уровнях модели деятельности
предприятия;
• возможность учитывать все существующие варианты выполнения
бизнес-процесса;
• возможность реализации сложных бизнес-процессов.
В то же время к недостаткам нотации EPC следует отнести:
• необходимость добавлять события даже после несущественных
(или промежуточных) действий, что в конечном счете может привести
к усложнению диаграммы;
51
• вероятность появления организационных разрывов в силу неудоб-
ства в отслеживании назначений;
• необходимость в учете всех ресурсов и результатов, что в конечном
счете может привести к перегрузке диаграммы объектами разного типа;
• необходимость в отображении всех исполнителей, что в конечном
счете может привести к избыточному количеству пересечений и повторе-
ний однотипных субъектов.
Удобство нотации EPC заключается главным образом в том, что реа-
лизованные в ней процессы удобны как для разработчиков и проект-
менеджеров, так и для конечных пользователей. В то же время для проек-
тирования сложной многоуровневой модели деятельности организации
нотация EPC может применяться только в комплексе с другими нотациями моделирования.
3.2.3. Методология моделирования BPMN
Нотация BPMN (Business Process Model and Notation – модель бизнеспроцессов и нотация) была разработана в 2001–2004 гг. группой BPMI.org
для стандартизованного визуального описания бизнес-процессов [3, с. 11].
Нотация направлена как на технических специалистов, которые отвечают
за разработку программного обеспечения и реализацию процессов, так
и на бизнес-архитекторов, занимающихся проектированием и оптимизацией бизнес-процессов, а также менеджеров, главная задача которых состоит в управлении этими процессами. Предназначение нотации BPMN
заключается прежде всего в том, чтобы обеспечить связь между описани-
ем бизнес-процесса и его выполнением. В 2004 году была выпущена вер-
сия 1.0 нотации, позже ей присвоили статус стандарта, затем была осу-
ществлена публикация версии 1.2. В 2013 году был издан стандарт
ISO/IEC 19510:2013 на нотацию BPMN [3, с. 11]. В настоящий момент методология BPMN развернута на базе множества программных инструментов, в том числе Business Studio, ARIS, Bizagi Modeler. В методологии
BPMN применяется достаточно понятный набор элементов, благодаря
наличию которых проектируются бизнес-процессы. Важно понимать, что
52
модели процессов, описанные с помощью методологии BPMN, имеют ста-
тус исполняемых в силу их реализации в любой системе BPM.
Нотация BPMN содержит лишь один тип диаграмм, а именно диаграммы бизнес-процессов; эти диаграммы дают возможность описать совокупность выполняемых действий в бизнес-процессе и другие аспекты
этого процесса. При описании бизнес-процесса в нотации BPMN применяются следующие типы объектов:
• Объекты потока (действия, события и шлюзы);
• Связи;
• Разделительные дорожки (в том числе пулы);
• Артефакты.
Действия представляют собой объекты потока, которые находятся
в определенной последовательности и ведут к появлению конечного ре-
зультата. Действия можно разделить на задачи (элементарные действия,
которые нельзя декомпозировать) и подпроцессы (составные действия,
которые можно декомпозировать). Задачи и подпроцессы могут иметь
маркеры, которые отображают определенный набор характеристик их вы-
полнения.
События в нотации BPMN являются индикаторами начала, прерыва-
ния и окончания бизнес-процесса. Следовательно, события можно разде-
лить на три типа: начальные, конечные и промежуточные. Начальные и
промежуточные события могут иметь триггеры, которые служат для обо-
значения причины события. По триггеру события делятся на следующие
типы: Неопределенное (без триггера), Сообщение, Таймер, Условие, Сиг-
нал, Множественное, Параллельное множественное, Эскалация, Ошибка,
Ссылка, Компенсация, Завершение [23]. Применение конечных событий
позволяет более наглядно указать на результат выполнения процесса.
Шлюзы – это элементы нотации, предназначенные для ветвле-
ния/слияния нескольких вариантов хода процесса. Шлюзы можно разде-
лить на несколько категорий: категория единственного выбора, категория
множественного выбора, категория сложного выбора, категория парал-
лельного исполнения.
53
Шлюзы единственного выбора, как правило, основаны на данных
(решение о дальнейшем варианте выполнения процесса принимается пу-
тем проверки условий) или на событиях (решение о дальнейшем варианте
выполнения процесса принимается путем анализа события, которое про-
исходит в данной точке процесса).
Шлюз категории множественного выбора интерпретируется как выражение «ИЛИ». Данный шлюз применяется в тех случаях, когда выбирается любой вариант выполнения процесса или сочетание вариантов.
Шлюз категории сложного выбора используется для того, чтобы за-
фиксировать сложные условия слияния и ветвления вариантов выполне-
ния процесса, которые невозможно показать с помощью других категорий
шлюзов. Применение такого шлюза обосновано, когда есть потребность
в том, чтобы выбрать вариант выполнения процесса исходя из состояния
процесса в данный момент. Также шлюз сложного выбора может заменить
несколько шлюзов единственного выбора.
Шлюз категории параллельного исполнения интерпретируется как
выражение «И». Данный шлюз ориентирован на слияние двух или более
действий или на запуск исполнения нескольких параллельных действий.
Одним из основных элементов нотации BPMN являются связи. Следует выделить три основных типа связи: связи потока, связи сообщений
и ассоциации. Для связи элементов потока, а именно событий, действий,
шлюзов, служит поток управления. Стандартный поток управления не
контролируем в силу того, что на него не имеют воздействие какие-либо
условия. Условный поток управления ограничен, поскольку выполнение
процесса по этому потоку будет происходить только в случае соблюдения
заданного условия. Поток управления по умолчанию применяется в том
случае, если не выполняется ни одно из условий, которые обозначены на
условных потоках управления.
В отличие от потока управления поток сообщений не показывает ход
выполнения процесса, а отображает межпроцессное взаимодействие с по-
мощью передачи сообщений или объектов. Поток сообщений может ини-
54
циировать стартовое событие, передавать сообщения и объекты из внеш-
него процесса в один из подпроцессов рассматриваемого процесса
и наоборот, а также передавать сообщения или объекты во внешний процесс, инициируя конечное событие.
Третий тип связи – ассоциация – предназначен для того, чтобы опре-
делять связи объектов данных и баз данных с процессами. С помощью
ассоциаций можно устанавливать два типа связи: связь процесса с объек-
том данных (базой данных) и связь объекта данных (базы данных) с про-
цессом.
Еще один элемент нотации BPMN – это разделительные дорожки.
К разделительным дорожкам относятся пулы, обычные дорожки, сверну-
тые пулы. Под пулом следует понимать совокупность всех действий биз-
нес-процесса и исполнителей этих действий. Пул служит для установления границ процесса, т. е. связи потока не могут пересекать границы пула.
За разграничение ответственных исполнителей внутри пула отвечают до-
рожки, которых в рамках одного пула может быть несколько. Взаимосвязи
между процессом внутри пула и внешних процессов осуществляются
с помощью потоков сообщений. Внешний (по отношению к текущей диа-
грамме) процесс представляется с помощью свернутого пула. Свернутый
пул используется для отображения процесса или внешней ссылки, откуда
приходит или куда передаются сообщения, а также для отображения
предыдущего или следующего процесса по отношению к текущему
процессу.
Под артефактами подразумеваются такие элементы, как объекты дан-
ных, аннотации и группировки. Объекты данных включают в себя различ-
ные документы, товарно-материальные ценности, программные средства
и т. д. Особенность объектов данных заключается в том, что они не оказы-
вают прямого влияния на потоки управления и сообщений. Текстовые ан-
нотации (сноски) позволяют бизнес-архитектору показать на диаграмме
дополнительную информацию о процессе в виде комментариев. Группи-
ровки объединяют любые элементы бизнес-процессов для большей
наглядности.
55
Можно выделить основные правила и рекомендации описания модели
бизнес-процессов с применением методологии BPMN:
1. Потоки действий необходимо использовать для описания порядка
следования и выполнения процессов. При этом они не должны пересекать
границы подпроцессов.
2. Потоки сообщений должны раскрывать взаимодействия между
участниками процесса.
3. События, которые локализуются на границах бизнес-процессов,
могут иметь не менее одного исходящего потока работ, при этом они не
должны иметь входящих потоков.
4. Начальное событие в подпроцессе не должно относиться к какому-
либо конкретному типу.
5. При задании имен элементам необходимо использовать ключевые
слова, которые отражают суть процесса. Все действия, события, объекты
данных должны иметь наименования.
6. Шлюзы применяются для ветвления/слияния потоков, но они не
выполняют какое-либо действие; шлюзы слияния могут не иметь наименований.
7. Шлюзы ветвления лучше задавать вопросительными формули-
ровками.
8. Условным потокам управления необходимо давать наименования
в согласованности с условиями их возникновения.
9. Имена событий, характеризующих состояния процесса, должны
раскрывать суть этих состояний.
10. Поток по умолчанию следует располагать вдоль центральной оси
процесса.
11. Для каждого процесса следует задавать начальное и конечное со-
бытия.
12. Если потоки процесса ведут к одному результату, необходимо
выполнить их слияние посредством события окончания.
Пример спроектированного бизнес-процесса в нотации BPMN пред-
ставлен на рис. 3.4.
56
Рис. 3.4. Пример реализованного бизнес-процесса в нотации BPMN
57
Таким образом, нотация BPMN позволяет проектировать модели внут-
ренних процессов организации, внешних процессов и процессов взаимодей-
ствия (масштабных процессов). Методология BPMN может применяться
для осуществления перевода спроектированной модели бизнес-процессов
в исполняемую модель на языке BPEL (Business Process Execution Language).
Из недостатков методологии можно отметить тот момент, что в BPMN
отсутствует возможность для описания информационной модели, организационной структуры. Это ведет к ограничениям применения данной методологии.
3.3. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML
3.3.1. Объектно-ориентированный подход
При проведении компьютерного моделирования наибольшей популярностью пользуются объектно-ориентированные языки. Для разработки
сложной системы важнейшее значение на этапах ее создания имеют проектирование и анализ этой системы в рамках объектной методологии.
Язык UML (Unified Modeling Language) служит для формирования моде-
лей информационных систем, которые в дальнейшем преобразовываются
в объектно-ориентированное программное обеспечение. Этот язык можно
интерпретировать как систему обозначений, основными элементами которой являются специализированные диаграммы. Язык UML по праву считается важным стандартом в области объектно-ориентированного моделирования. Он был создан в 1994 году Гради Бучем и Джимом Румбаха в результате слияния метода Буча и метода OMT (Object Modeling Technique).
Поскольку язык UML опирается на объектно-ориентированный подход, необходимо разобраться в базовых идеях этого подхода.
Следует понимать, что в основе объектно-ориентированного моделирования заложено понятие не функции, а объекта. Объект представляет
собой структуру, объединяющую данные и методы их обработки [16, с. 85].
Принцип наследования, выражающийся в построении новых объектов на
базе уже существующих путем их уточнения, расширения и наделения
58
свойствами, дает возможность создавать программное обеспечение с по-
мощью библиотечных объектов. Для всевозможных языков программиро-
вания были разработаны библиотеки стандартных классов объектов, реа-
лизующих базовые компоненты визуализации, например выпадающие
списки, окна, меню, кнопки [16, с. 85]. Библиотечные классы компонентов призваны вызывать подходящие методы. Получила распространение
концепция быстрой разработки приложений RAD (Rapid Application
Development), которая позволила генерировать большую часть программного кода. Разработчики стали углубляться в вопросы проведения анализа проблемной области и проектирования системы. С этим связано появление методов объектно-ориентированного анализа и проектирования
(OOA/OOD – Object-Oriented Analysis/Design), благодаря которым стало
возможно моделировать и документировать системы до начала разработки. Суть использования этих методов заключается в исследовании проблемы предметной области, описании требований к будущей системе
и решении задач проекта с точки зрения объектов (сущностей).
Анализ заключается в изучении проблематики предметной области.
На этапе анализа задача состоит в том, чтобы дать определение объектов
(сущностей) с применением терминов исследуемой области. Например,
при реализации новой информационной системы для мебельной фабрики
обязательно описываются ее производственно-экономические процессы.
В ходе описания этих процессов появляются сущности «Клиент», «По-
ставщик», «Продукция» и др.
На этапе проектирования выявляются объекты, которые будут реали-
зованы с помощью объектно-ориентированного языка программирования.
Для этих объектов описываются атрибуты и методы. Например, объект
«Продукция» будет иметь атрибуты «Наименование» и «Количество».
Иными словами, при проектировании делается акцент на логическом ре-
шении, которое будет удовлетворять заданным требованиям.
После анализа и проектирования системы наступает этап разработки,
который подразумевает саму реализацию разработанных компонентов на
выбранном языке объектно-ориентированного программирования. К таким языкам относятся, например, C++, Java, Python и др.
59
Поскольку модель является полным отражением разрабатываемой си-
стемы, благодаря стадиям анализа и проектирования намного легче обна-
ружить недостатки системы и исправить их без значительных затрат. Язык
UML стал тем инструментом, который воссоединил в себе самые известные методы объектно-ориентированного анализа и проектирования,
вследствие чего стал востребованным среди разработчиков. Основными
элементами данного языка, как уже говорилось выше, являются диаграм-
мы. Диаграммы можно разделить на два типа:
• диаграммы, описывающие структуру системы – классы, подсисте-
мы, компоненты и т. д.;
• диаграммы, описывающие поведение системы, а именно функцио-
нал системы, логику процессов, взаимодействие объектов и др. [16, с. 86].
Благодаря UML строятся модели бизнес-процессов даже в случае от-
сутствия их автоматизации. Вместо программных объектов в этих моде-
лях описываются конкретные объекты бизнес-процессов (продукция, ответственные сотрудники). Окружение информационной (совокупность
пользователей) системы заменяет окружение конкретного бизнеса (клиенты, поставщики, спонсоры).
Необходимо подчеркнуть, что моделирование бизнеса с применением
UML ведет к проектированию следующих моделей:
1) прецедентной модели, которая отображает функционал: варианты
использования и их взаимосвязи с внешним окружением;
2) объектной модели, которая отображает совокупность составляю-
щих объектов, являющихся участниками бизнес-процессов.
Таким образом, язык UML дает возможность описать разрабатываемую систему с разных ракурсов ее поведения, а также сократить количе-
ство ошибок, связанных с несогласованным изменением атрибутов. Дан-
ный язык достаточно прост в понимании и освоении синтаксиса построе-
ния диаграмм. В то же время UML сравнительно часто подвергается критике в силу избыточности, т. е. большого числа редко используемых диа-
грамм, и необходимости введения дополнительных способов представле-
ния информации об исследуемой области.
60