Конспект лекций case cals. Конспект_САСТ-2. Конспект лекций по дисциплине case и cals технологии по направлению подготовки
 Скачать 3.53 Mb.
|
|
9. Описание бизнес-процессов с использованием обозначений BPMN. Язык моделирования бизнес-процессов BPML 9.1. Нотация BPMN Основным инструментом BPMN служит диаграмма бизнес-процессов (Business Process Diagram, BPD). Полученная в результате модель представляет собой сеть графических объектов, которые изображают действия, связанные по- токами управления. 9.1.1. Типы процессов в нотации BPMN В рамках общей нотации BPMN существует три типа процессов: –– частные, или внутренние, процессы (Private) — внутренние процессы определённой организации; –– абстрактные, или открытые, процессы (Abstract) — взаимодействие ме- жду процессами на уровне обмена сообщениями; 153 –– совместные, или глобальные, процессы (Collaboration) — два и более абстрактных процесса на одной диаграмме. Частные бизнес-процессы обычно называют WorkFlow или процессами BPM (управление деловыми процессами). На диаграммах BPMN каждый част- ный бизнес-процесс помещается в отдельную область, и таким образом последо- вательный поток процесса содержится внутри области и не может пересекать её границы. При этом поток сообщений может пересекать границы области с целью указания на взаимодействия, существующие между отдельными частными биз- нес-процессами. Абстрактными считаются процессы, действия которых имеют связи за пределами частного бизнес-процесса. Кроме того, к абстрактным процессам от- носятся соответствующие механизмы контроля потока. Абстрактные процессы содержатся внутри области и могут моделироваться отдельно или внутри общей схемы BPMN для демонстрации потока сообщений между блоками абстрактного процесса и другими объектами. Совместный процесс отображает взаимодействие между двумя и более бизнес-объектами. Его можно изобразить в виде двух или более взаимодейст- вующих абстрактных процессов. 9.1.2. Точки зрения Диаграмма BPMN может отображать процессы разных участников, каж- дый из которых может иметь свой взгляд на неё. По отношению к участнику од- ни действия будут внутренними, а другие — внешними. Во время выполнения процесса разница между внутренними и внешними действиями имеет большое значение для определения участником статуса действия или для поиска проблем. Однако сама схема останется неизменной. Поэтому проектирование процессов рекомендуется разделять по следующим уровням: –– бизнес-уровень (Business Layer) — общее представление различных бизнес-шагов и управляющих ими потоков; 154 –– функциональный уровень (Functional Layer) — общее представление о взаимодействии процессов с базами данных, проектирование формата обмена сообщениями; –– уровень реализации (Implementation Layer) — схема реализации деталей процесса. Все уровни зависимы между собой, и просто предлагают различное пред- ставление одного и того же процесса. 9.1.3. Объекты потока процесса В BPMN определены следующие типы объектов: –– деятельность (Activity) — действия, выполняемые участниками процес- са; –– соединитель потоков (Flow Connector) — связь между объектами про- цесса; –– событие (Event) — спецификация существенных явлений в поведении системы (т.е. явления, влияющие на поток процесса); –– шлюз или объединение (Gateway) — точка принятия решений в диа- грамме процесса, после которой поток процесса может быть продолжен по од- ному или более путям; –– дорожка (Swimlane) — область диаграммы, содержащая элементы мо- дели отдельного участника процесса; –– артефакт (Artifact) — документы и комментарии. Деятельность состоит из атомарных или составных действий, характери- зующих работу, которую выполняет система. Деятельность подразделяется на задачи и подпроцессы. Задача (Task) представляет собой элементарное действие в пределах про- цесса. Задачи могут быть простыми и повторяющимися. Графически задачи изо- бражаются в виде прямоугольника со скруглёнными углами (рис. 9.1), могут со- держать метку (Label), документацию (Documentation), связанную с задачей, тип повторения задачи (Loop Type). 155 Рис. 9.1. Графическое изображение задачи в нотации BPMN Задачи могут объединяться в подпроцессы (Sub-process) — сложные дей- ствия в пределах процесса. Подпроцессы могут быть обычными и повторяющи- мися, сжатыми и расширенными (рис. 9.2). Рис. 9.2. Графическое изображение подпроцесса в нотации BPMN Соединители потоков (коннекторы) используются для соединения элемен- тов потока процесса (табл. 9.1). Таблица 9.1 Типы коннекторов в нотации BPMN Графический имвол Название элемента простой поток условный поток 156 Графический имвол Название элемента поток по-умолчанию поток сообщений ассоциация Последовательный (простой) поток (Sequence Flow) используется для ото- бражения порядка следования действий процесса. Графически последователь- ный поток изображается сплошной линией с закрашенной стрелкой. Условный поток — последовательный поток с условным выражением, из- меряемым по времени выполнения, с целью определить, будет ли использовать- ся поток. Графически условный поток изображается сплошной линией с закра- шенной стрелкой и ромбиком на противоположном конце. Поток по-умолчанию — условный поток, который будет использоваться в случае, если все другие условные потоки не верны при выполнении. Графически поток по-умолчанию изображается сплошной линией с закрашенной стрелкой и косой чертой на противоположном конце. Поток сообщений (Message Flow) используется для отображения потока сообщений между двумя отдельными участниками процесса. Графически поток сообщений изображается пунктирной линией с незакрашенной стрелкой и неза- крашенным кружочком на противоположном конце. Ассоциация (Association) используется для того, чтобы связать данные, текст и другие артефакты с потоком объектов процесса. Графически ассоциация изображается пунктирной линией с V-образной стрелкой. Событие представляет собой нечто, происходящее в ходе бизнес-процесса и влияющее на его течение. Так, указание типа триггера (условия или ограниче- ния) на событие устанавливает определённые ограничения на процесс потока. Также события могут приводить бизнес-процесс к некоторому результату. Существует три типа событий (рис. 9.3), классифицированных по времени воздействия на ход процесса: начальные (Start Events), промежуточные 157 (Intermeidate Events) и конечные (End Events). Начальные и конечные события представляют собой точки начала и окончания процесса и должны обязательно присутствовать на диаграмме. Рис. 9.3. Графическое изображение начального, промежуточного и конеч- ного событий в нотации BPMN В нотации BPMN определены следующие типы триггеров (табл. 9.2): –– сообщение (Message) — исходит от некоторого участника или триггера процесса и предшествует началу, продолжению или окончанию некоторого дей- ствия процесса; –– таймер (Timer) — устанавливает цикл времени течения процесса; –– правило (Rule) — тестовая строка, описывающая некоторое правило, применяемое к событию; –– исключительное событие (Exception) — при завершении некоторого действия информирует процесс о возникновении ошибки; –– компенсация (Compensation) — показывает, как подпроцесс может быть скомпенсирован последовательностью отката; –– отмена (Cancel) — указывает на отмену события; –– ссылка (Link) — представляет собой механизм, обеспечивающий под- ключение окончания события одного потока процесса к началу события другого потока процесса; –– составное событие (Multiple) — указывает на то, что событие может за- действовать несколько путей развития процесса или продолжить процесс в слу- чае наличия промежуточного события. 158 Таблица 9.2 Типы триггеров в нотации BPMN Графический имвол Название элемента события с триггером «сообщение» события с триггером «таймер» события с триггером «правило» события с триггером «исключитель- ное событие» события с триггером «компенсация» события с триггером «отмена» события с триггером «ссылка» события с триггером «составное со- бытие» 9.1. Нотация BPMN Шлюз (или объединение) используется для контроля расхождения и схож- дения последовательного потока и обозначает ветвление или соединение мар- шрутов (табл. 9.3). Внутренние маркеры указывают на тип контроля развития процесса. Шлюзы могут определять направление потока на основе данных про- цесса (Data-Based) или на основе результатов наступления событий (EventBased). 159 Таблица 9.3 Типы шлюзов в нотации BPMN Графический имвол Название элемента Шлюз шлюз на основе данных процесса с оп. XOR шлюз на основе результатов наступ- ления событий с оп. XOR шлюз на основе результатов наступ- ления событий с оп. OR шлюз с оп. AND шлюз со сложным условием В нотации BPMN определены следующие виды шлюзов: –– шлюз на основе данных процесса с операцией «исключающее ИЛИ» (Exclusive (XOR) Data-Based) — может выполняться только одна из ветвей про- цесса; 160 –– шлюз на основе результатов наступления событий с операцией «исклю- чающее ИЛИ» (Exclusive (XOR) Event-Based) — может выполняться только одна из ветвей процесса; –– шлюз на основе результатов наступления событий с операцией «ИЛИ» (Inclusive (OR) Event-Based) — могут выполняться одна или более ветвей про- цесса; –– шлюз с операцией «И» (Parallel (AND)) — все ветви процесса выполня- ются параллельно; –– шлюз со сложным условием (Complex). Дорожки представляют собой участников процесса и группируют процесс по ответственности и категориям исполнителей (рис. 9.4). Рис. 9.4. Графическое изображение дорожек в нотации BPMN В BPMN определены следующие типы артефактов (табл. 9.4): –– данные об объекте (Data Objects) — представляют собой дополнитель- ные данные об объекте, графически изображаются в виде прямоугольника с «за- гнутым» верхним правым уголком; –– группа (Groupe) — используется для документации или анализа целей, но не влияет на последовательность потоков; –– аннотация (Annotation) — предоставляет дополнительную информацию для читателя диаграмм BPMN. 161 Таблица 9.4 Артефакты в нотации BPMN Графический имвол Название элемента данные об объекте группа аннотация 9.1.4. Пример диаграммы BPMN На рис. 9.5 приведён пример BPMN-процесса «Доставка товара в магазин». Магазин отправляет заявку на товар дистрибьютору. Дистрибьютор подтвержда- ет получение заявки, запрашивает товар со склада. Перед отправкой товара со склада проверяется наличие товара, при необходимости товар заказывается у по- ставщика, после чего товар доставляется грузоперевозчиком в магазин. 162 Рис. 9.5. Пример BPMN процесса «Доставка товара в магазин» 9.2. Язык моделирования бизнес-процессов BPML Язык моделирования бизнес-процессов (Business Process Modeling Language, BPML) базируется на метаязыке XML. Бизнес-процесс в BPML соот- ветствует иерархическому набору вложенных и последовательных тегов. BPML предназначен для представления формальной модели, описывающей процессы, выполняемые в системе, которые определяют все аспекты корпоративных биз- нес-процессов. BPML задаёт операции разного уровня сложности, транзакции и компенсации, управление данными, параллелизм, обработку исключений и опе- рационную семантику. В основе BPML лежит язык XML, поэтому грамматика BPML оформляется в виде XML-схемы, что обеспечивает постоянство опреде- лений и их обмен между гетерогенными системами и инструментами моделиро- вания. BPML может применяться для более детального определения процессов. 163 Он преобразует бизнес-операции в сообщения, которыми обмениваются процессы. WorkFlow-процесс в BPML определяется при помощи элементов: деятель- ность (Activity), сигнал (Signal), исключение (Exception), контекст (Context), свойство (Property). Деятельность (Activity) является основным элементом бизнес-процесса. Элементы Activity могут соединяться последовательно (простые) или вкладываться один в другой (сложные). Разные типы деятельности выполняют различные функции.Также существуют типы деятельности, которые запускают дочерние процессы (как с ожиданием их окончания, так и без), организуют за- держки выполнения процесса и т.д. Кроме того, есть несколько типов деятельно- сти, реализующих разного вида циклы. Синтаксис базового типа bpml:activity имеет вид: <{activity type} name = NCName {other attributes}> Content: (documentation?, {other element}*) BPML спецификация определяет следующие виды деятельности –– простые: – Action — выполняет или запускает операции обмена входящими и исхо- дящими сообщениями; – Assign — присваивает новое значение свойству; – Call — запускает процесс и ждёт его завершения; – Compensate — вызывает компенсации указанных процессов; – Delay — выражает течение времени; – Empty — ничего не делает; – Fault — выдаёт сообщение об ошибке в текущем контексте; – Raise — активизирует сигнал; – Spawn — запускает процесс, не дожидаясь его завершения; – Synch — синхронизирует по сигналу; 164 –– сложные: – All — выполняет указанные операции параллельно; – Choice — выполняет операции одного из составных комплектов, вы- бранного в соответствии с возникшим событием; – Foreach — однократно выполняет операции для каждого пункта из спи- ска; – Sequence — выполняет операции последовательно; – Switch — выполняет операции одного из составных комплектов, выбран- ного на основе истинного значения условия; – Until — выполняет операции один или более раз на основе истинного значения условия; – While — не выполняет операции или выполняет их один или более раз на основе истинного значения условия. Для деятельности определены следующие состояния: –– ready — деятельность находится в состоянии готовности; –– active — деятельность находится в активном состоянии (работает); –– completing — деятельность совершает действия для завершения выпол- ненных работ; –– completed — деятельность полностью завершила выполняемые дейст- вия; –– aborting — деятельность совершает действия для прерывания выпол- няемых работ; –– aborted — деятельность полностью завершила действия для прерывания выполняемых работ. Синтаксис для определения элемента Action имеет вид: 165 role = QName {extension attribute}> Content: (documentation?, (input | output)*, {any activity}*) Синтаксис для определения входящего элемента имеет вид: Синтаксис для определения исходящего элемента имеет вид: Синтаксис элемента Assign имеет вид: Content: (documentation?, ((source | value)+ | {extension element})?) Синтаксис элемента Source имеет вид: Content: ({extension element})?) Синтаксис элемента Call имеет вид: 166 Content: (documentation?, output*, input*) Синтаксис элемента Compensate имеет вид: Content: (documentation?, output*) Синтаксис элемента Delay имеет вид: Content: (documentation?) Синтаксис элемента Empty имеет вид: Content: (documentation?) Синтаксис элемента Fault имеет вид: Content: (documentation?) Синтаксис элемента Raise имеет вид: Content: (documentation?, output*) 167 Синтаксис элемента Spawn имеет вид: Content: (documentation?, output*) Синтаксис элемента All имеет вид: Content: (documentation?, context?, {any activity}+) Синтаксис элемента Choice имеет вид: Content: (documentation?, event{2,*}) Content: (documentation?, (action | synch | delay), context?, {any activity}+) Синтаксис элемента Foreach имеет вид: Content: (documentation?, context?, {any activity}+) Синтаксис элемента Sequence имеет вид: Content: (documentation?, context?, {any activity}+) Синтаксис элемента Switch имеет вид: 168 Content: (documentation?, case+, default?) Content: (documentation?, condition, context?, {any activity}+) Content: (documentation?, context?, {any activity}+) Синтаксис элемента Until имеет вид: Content: (documentation?, condition, context?, {any activity}+) Синтаксис элемента While имеет вид: Content: (documentation?, condition, context?, {any activity}+) Сигналы (Signals) используются для синхронизации точек управления, на- ходящихся в элементах Activities одного уровня вложенности. Синтаксис для определения сигнала имеет вид: Content: (documentation?, (value | source)?) Content: (condition?) 169 Двумя важными компонентами модели BPML являются системные ошиб- ки (Faults) и планировщики (Schedules). Системные ошибки (как и исключительные события) приводят к заверше- нию выполнения текущего задания, в результате чего управление передаётся специальным обработчикам (системным или определённым в контексте). Синтаксис для определения системных ошибок имеет вид: Content: ((case+, default?) | default) Content: (documentation?, {any activity}+) Content: (documentation?, {any activity}+) При этом элемент case используется, если заданы более одного кода неис- правности, а элемент default используется, если не указаны специальные ошибки кодов. Планировщики выполняют управляющие функции: в их задачу входит ге- нерация специальных сообщений в определённые моменты времени, что позво- ляет осуществлять планирование запуска процессов. Синтаксис для определения планировщика имеет вид: Content: (documentation?, {extension element}?) 170 Исключение (Exception) соответствует возникновению нештатной ситуа- ции, когда оказывается, что выполнять некоторый участок бизнес-процесса уже не требуется 2 Синтаксис для определения исключения имеет вид: Content: (documentation?, event, context?, {any activity}+) Компенсация (Compensation) соответствует необходимым действиям по корректному завершению ситуации, возникшей в связи с Exception 3 Синтаксис для определения компенсации имеет вид: Content: (documentation?, (event | parameters?), context?, {any activity}+) Контекст (Context) содержит относящиеся к процессу переменные, локаль- ные определения процессов, сигналов и т.д., служит для синхронизации и пере- дачи информации между узлами. Синтаксис для определения контекста имеет вид: Content: ((exception | process | property | schedule | signal)*, faults?) Переменные определяются набором свойств (Property) и могут быть ло- кальными или глобальными по отношению к данному контексту. 2 Например, __________во время выполнения бизнес-процесса оформления туристиче- ской поездки клиент позвонил в туристическую компанию и сообщил, что он отказывается от поездки. 3 Если до отказа клиента от поездки для клиента были забронированы билеты на само- лёт и номер в гостинице, то задачей элемента Compensation будет отменить бронирование. 171 Синтаксис для задания свойств имеет вид: name = NCName type = QName element = QName fixed = boolean> Content: (documentation?, value?) Следует отметить, что синтаксис конструкций для взаимодействия бизнес- процесса с внешними приложениями и исполнители не определены в языке BPML — все это перенесено на технологию Web-сервисов. |