Full Text

Введение. Использование активных форм обучения становится одним из значимых компонентов изменения процесса преподавания. Применение активных методов на практике обусловлено тем фактором, что обучаемые приобретают не только теоретические знания, но также получают критические умения и навыки. К подобным методам относятся мозговой штурм, тренинги, дискуссии, деловые игры и т.д. В современном обучении широко распространяются деловые игры (ДИ), которые могут моделировать реальные условия деятельности определенной компании. В связи с этим фактом растет число программных продуктов, которые автоматизируют проведение деловых игр. В качестве таких примеров можно привести SimulTrain компании Sauter Training & Simulation, MobLab компании MobLab Inc, Innov8 компании IBM. Несмотря на то, что такие продукты являются мощным инструментом для создания деловых игр, они ориентированы на конкретную предметную область [1-3]. К тому же стоимость таких продуктов очень высока. Для моделирования деловой деятельности вне зависимости от предметной области была разработана концепция «Студии компетентностных деловых игр» (далее - СКДИ) [4]. СКДИ состоит из различных подсистем, которые воссоздают единое пространство для управления жизненным циклом деловой игры (табл. 1). Таблица 1 Подсистемы СКДИ Подсистема Назначение Проектирование Разработка сценария деловой игры на основе описания бизнес-процессов Проведение Проведение игры с использованием автоматной и операционной моделей из подсистемы проектирования Мониторинг Отслеживание промежуточных результатов игроков во время игры и формирование статистики для подсистемы анализа Анализ Анализ итогов деловой игры, составление отчетов о результатах деловой игры, результатах игроков Измерение Вычисление уровня выработанных в ходе деловой игры компетенций Корректировка Внесение поправок в сценарии деловой игры с учетом результатов данных подсистемы анализа В качестве предметной области при проектировании ДИ выступают бизнес-процессы реальных предприятий, исполнители которых должны обладать определёнными компетенциями. Как правило, такая информация представляет собой неформализованное или слабоформализованное описание. Для получения формализованного описания ДИ используется последовательная трансформация моделей бизнес-процессов [4]: - рабочий бизнес процесс (РБП) может быть представлен с помощью визуальных моделей бизнес-процессов в различных нотациях (IDEF0, IDEF3, DFD, BPMN, ARIS EPC, диаграммы активности UML и т.д.), а также текстовых описаний; - унифицированный бизнес-процесс (УБП) - визуальная модель, которая отражает существенные инвариантные характеристики реального бизнес-процесса; - учебный унифицированный бизнес-процесс (УУБП) - визуальная модель, в которую добавлены обучающие элементы, с помощью которых создается возможность выбора ресурсов и принятия решений игроком. Эти модели относятся к слабоформализованному описанию предметной области деловой игры, поэтому переход от РБП к УБП является сложной задачей. Входными параметрами для трансформации являются РБП, которые могут быть представлены в виде текстового описания и/или визуальных моделей. В данной работе рассматривается трансформация РБП, представленных с помощью диаграмм в нотации IDEF0 (табл. 2) [5], в УБП. Для разработки процесса трансформации необходимо описать метамодели языков, правила трансформации и непосредственно сам процесс трансформации. Таблица 2 Элементы нотации IDEF0 Элемент Описание Функциональный блок Обозначает конкретное действие, указывается обычно название действия и его номер. В графическом виде представляет собой прямоугольник Интерфейсная дуга - входной поток Обозначает информацию, которая поддается на вход функционального блока для ее преобразования. Наличие стрелки входа у функционального блока необязательно. В графическом виде представляет собой стрелку, входящую в блок Интерфейсная дуга - выходной поток Обозначает продукцию или информацию, которая получается в результате работы функционального блока. Наличие стрелки выхода у функционального блока обязательно. В графическом виде представляет собой стрелку, выходящую из блока Управление Обозначает управление функционального блока. Наличие стрелки у функционального блока входа необязательно. В графическом виде представляет стрелку, направленную вниз в функциональный блок Механизм Обозначает ресурсы (персонал, техника, оборудование), которые непосредственно выполняют моделируемое действие. Наличие стрелки механизма исполнения у функционального блока необязательно. В графическом виде представляет стрелку, направленную вверх в функциональный блок В состав унифицированного бизнес-процесса входят операции, образующие определенную последовательность, и условия, по которым выполняются те или иные операции [6-8]. Язык описания унифицированного бизнес-процесса состоит из двух метамоделей: «Последовательность операций» и «Операция». Описание языка представлено в табл. 3. Таблица 3 Язык описания унифицированных бизнес-процессов Метамодель Элемент Описание Последовательность операций Начало БП Итерация бизнес-процесса конечна, поэтому необходимо выделить начало и конец итерации, для чего используются объекты «Начало БП» и «Завершение БП» Операция Данный объект отражает активность в бизнес-процессе Условие Иногда выбор следующей операции зависит от выхода предыдущей операции, который может быть произведен с помощью некого условия, которое поможет определить дальнейшие действия Завершение БП Итерация бизнес-процесса конечна, поэтому необходимо выделить начало и конец итерации, для чего используются объекты «Начало БП» и «Завершение БП» Операция Контрагент Данный объект отражает объекты внешней среды Операция Данный объект отражает активность в бизнес-процессе Поток Потоки отражают используемые и изменяемые ресурсы в операции Трудовой ресурс Трудовой ресурс выполняет операцию Информационный ресурс Информационный ресурс может регламентировать операцию или быть изменен, или добавлен в процессе ее выполнения Услуга Услуга может быть произведена при выполнении операции, а также потреблена или продана Товар Товар может быть получен, произведен или потреблен в процессе выполнения операции Финансовый ресурс Финансовый ресурс может уменьшаться или увеличиваться с выполнением операции Оборудование Отражает оборудование, необходимое для выполнения операции Подходы к трансформации визуальных моделей. Существуют различные подходы для трансформации визуальных моделей, на основе которых разработаны соответствующие инструменты [9]: AGG (Attributed Graph Grammar) - инструментальная среда для описания и осуществления трансформации на основе типизированных атрибутных графов [10]. AGG состоит из инструмента проверки допустимости, интерпретатора и графического интерфейса, в котором несколько визуальных редакторов. В визуальных редакторах реализована возможность редактирования правил, графов и графовых грамматик. Каждый элемент графа в AGG имеет определенный тип из заданного множества типов, которое состоит из двух подмножеств: набора типов вершин и набора типов ребер. При описании атрибута пользователь должен указать имя и тип атрибута. После описания графов моделей пользователю необходимо задать правила их преобразования. В AGG возможны два подхода к определению трансформации: - подход одинарного выталкивания (SPO), в котором правило представляет собой левую (LHS) и правую (RHS) часть вместе с частичным морфизмом графа r:LHS→ RHS [11]; - подход двойного выталкивания (DPO), в котором присутствует дополнительный граф склеивания I, т.е. r: LHS ←I→ RHS [12]. Одно из преимуществ AGG - возможность проверки правил трансформации, допустимости и проверки непротиворечивости графов. Другое преимущество AGG заключается в том, что в данной среде можно разделять правила по уровням. Такое разделение правил по уровням позволяет определять порядок применения правил и задать протокол управления в преобразовании графа. QVT (Query/View/Transformation) - стандарт трансформации моделей, в котором несколько языков преобразования моделей. Ключевыми понятиями этого стандарта являются: запрос, представление, трансформация [13]. Запрос в QVT по построению аналогичен запросу SQL к реляционной БД. В свою очередь, запрос является частным случаем представления. Под представлением принято принимать модель, которая получена из другой (основной) модели. Модели трансформируют и получают целевую модель из исходной модели. Процесс трансформации основывается на правилах и соответствии, при котором элементы левой и/или правой модели удовлетворяют условиям фильтра правила. Соответствие инициирует создание элементов целевой модели, управляемой описанием и/или реализацией соответствующего правила. Основным преимуществом QVT является широкий набор языков описания трансформаций, которые позволяют использовать как стандартные средства, так и их расширения. Тем не менее есть и недостатки. В QVT используется стандарт MOF как язык метамоделирования, что не позволяет пользователю выбрать удобный для него метаязык, а также изменить описание метаязыка, интегрированного в QVT. Кроме того, пользователь не может осуществить трансформацию вида «модель-текст», так как каждая метамодель должна быть описана с помощью стандарта MOF. GReAT (Graph REwriting And Transformation) - язык описания преобразований моделей, базирующийся на тройных графовых грамматиках. Преобразование моделей основывается на правилах переписывания графа, которые применяются к исходной модели и в результате создают целевую модель [14]. Для спецификации исходной и целевой метамоделей используются диаграммы классов UML и ограничения, описанные на языке OCL. UML позволяет определять структурные ограничения, в то время как OCL может быть использован для задания неструктурных ограничений. Таким образом, диаграмма классов UML играет роль графовой грамматики, с помощью которой могут быть созданы метамодели предметных областей. Данный язык использует модифицированный аппарат графовых грамматик. Грамматика по-прежнему состоит из набора правил, но правило уже не разбивается на левую и правую части, как это предполагается в классических графовых грамматиках. Вместо этого строится один граф, содержащий как левую, так и правую часть правила. Каждый элемент (вершина или ребро) может быть помечен одним из специальных символов, который указывает способ обработки этого элемента: «создание», «удаление» и др. Другой подход к трансформации моделей основан на применении онтологии и метамоделей [15-17]. Такая трансформация имеет следующее преимущества: - использование запросов в онтологии для поиска и обработки информации; - расширяемость за счет добавления новых метамоделей в онтологию; - проверка моделей на соответствие семантическим правилам, указанным в онтологии. Такая проверка позволяет выявить логические несоответствия, присутствующие в моделях; - целостное представление предметной области. Таким образом, был выбран подход трансформации бизнес-процессов на основе онтологии. Трансформация РБП в УБП. Рассмотрим трансформацию РБП, описанного с помощью нотации IDEF0, в УБП. Трансформация заключается в сопоставлении элементов моделей РБП и УБП, что позволит перейти от одной диаграммы к другой. Для этого необходимо выполнить следующие шаги: Шаг 1. Построить онтологическую модель для описания нотации РБП: элементы и их графическое представление в нотации IDEF0. Шаг 2. Построить онтологическую модель для описания нотации УБП: элементы и их графическое представление. Шаг 3. Разработать соотношения между элементами и их графическим представлением как для РБП, так и для УБП. Шаг 4. Разработать правила перехода от РБП к УБП. Шаг 5. Построить онтологическую модель, в которой будут отражены правила сопоставления элементов РБП и УБП для осуществления трансформации. Шаг 6. Создать запрос в онтологии, который выводит соответствие элементов одной нотации другой нотации. Таким образом, будет создана онтология, содержащая в себе элементы и их графическое представление в РБП и УБП. Для того чтобы соотнести элементы РБП и УБП, задаются ограничения. После чего создается запрос, который на основании ограничений выводит сопоставление элементов РБП и УБП. На рис. 1 представлены элементы и их графические представления РБП. Рис. 1. Состав и графическое представление элементов нотации IDEF0 Онтология для элементов и их графического представления в нотации IDEF0, построенная с помощью редактора онтологий Protégé [18], представлена на рис. 2. Рис. 2. Онтология элементов и их графического представления для нотации IDEF0 На рис. 3 приведены элементы, из которых состоит последовательность операций УБП и их графическое представление. Рис. 3. Состав и графическое представление элементов последовательности операций УБП Онтология для элементов и их графического представления в последовательности операций УБП, построенная с помощью редактора онтологий Protégé, представлена на рис. 4. Аналогично были рассмотрены элементы, их графические представления и онтология для диаграммы Операция УБП. Рис. 4. Онтология элементов и графического представления для последовательности операций УБП Далее было выполнено сопоставление между элементами в каждой нотации и их графическим представлением (рис. 5). В онтологии для описания соответствия элементов и их графических представлений созданы соответствующие ограничения. Рис. 5. Соответствие элемента «блок IDEF0» и его графического представления «прямоугольник» Следующим этапом является разработка правил трансформации. В табл. 4 показаны правила, построенные для трансформации РБП, представленного в нотации IDEF0, в модель «Последовательность операций УБП». Аналогичные правила разработаны для модели «Операция УБП». Эти правила должны быть отражены в онтологии. Для выполнения трансформации необходимо выполнить запрос, с помощью которого и будет построен соответствующий УБП. Таблица 4 Правила трансформации УБП и IDEF0 Элемент УБП Графический символ элемента УБП Элемент IDEF0 Графический символ элемента IDEF0 Последовательность операций УБП Операция Функциональный блок Условие Вход Выход Окончание табл. 4 Элемент УБП Графический символ элемента УБП Элемент IDEF0 Графический символ элемента IDEF0 Начало БП - - Завершение БП - - Связь Вход Выход Вход Выход На рис. 6 представлен фрагмент онтологии для последовательности операций УБП с указанием ограничения. Рис. 6. Соответствие элемента «Операция» в последовательности операции УБП и «Функциональный блок» в нотации IDEF0 Пример запроса, который выводит соответствие элемента «Функциональный блок» IDEF0 другим нотациям, приведен на рис. 7. Рис. 7. Соответствие функционального блока другим элементам УБП и РБП В результате выполнения рассмотренного выше алгоритма на основе моделей реальных бизнес-процессов будет получена модель унифицированного бизнес-процесса, содержащая функции для каждого исполнителя. На основе полученной модели УБП в дальнейшем генерируются сценарии ДИ [19, 20]. Выводы. В статье предложен алгоритм для трансформации реальных моделей БП в унифицированный бизнес-процесс. Для представления РБП была выбрана нотация IDEF0. Были описаны элементы и их графическое представление для используемых нотаций. Описание элементов и правила трансформации отражены в построенной онтологии с целью реализации запроса в онтологии, который выводит соответствие элементов одной нотации другой нотации. Необходимо отметить, что в разработанных правилах трансформации присутствуют потери, связанные с элементами и связями. Более того, разработанный запрос не отображает порядок последовательности расположения элементов. Таким образом, при использовании разработанных правил пользователю необходимо доопределить недостающие элементы и определить порядок последовательности элементов. В дальнейшем планируется расширить количество нотаций для описания реальных бизнес-процессов и предложить шаблон для текстового описания РБП. Это необходимо для правильного доопределения построенных моделей. Данный алгоритм будет использован при реализации программного обеспечения, позволяющего автоматически генерировать сценарии и ресурсы деловой игры на основании неформализованного/слабоформализованного описания рабочего бизнес-процесса.

About the authors

O. L Vikenteva

National Research University «Higher School of Economics»

A. I Deryabin

National Research University «Higher School of Economics»

O. A Ponomareva

National Research University «Higher School of Economics»

L. V Shestakova

National Research University «Higher School of Economics»

References

Statistics

Views

Abstract - 49

PDF (Russian) - 20

Refbacks

• There are currently no refbacks.