Реализация подсистемы проведения информационной системы проектирования и проведения деловых игр

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного образовательного учреждения высшего образования «Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

РЕАЛИЗАЦИЯ ПОДСИСТЕМЫ ПРОВЕДЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ ПРОЕКТИРОВАНИЯ И ПРОВЕДЕНИЯ ДЕЛОВЫХ ИГР

Выпускная квалификационная работа

по направлению подготовки 38.03.05 Бизнес-информатика

образовательная программа «Бизнес-информатика»

Найданов Илья Валерьевич

Пермь, 2019 год

Аннотация

Найданов И.В. Проектирование подсистемы проведения информационной системы проектирования и проведения деловых игр. - 43 с. 2019г.

Работа посвящена проектированию подсистемы проведения деловых игр для студии компетентностных деловых игр (СКДИ), разрабатываемой кафедрой информационных технологий в бизнесе в НИУ ВШЭ Пермь. Работа содержит 3 главы, в которых описан процесс анализа, проектирования и реализации подсистемы СКДИ, отвечающей за симуляцию деловой игры.

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



Оглавление

Введение

Глава 1. Анализ предметной области

1.1 Описание архитектуры СКДИ

1.2 Описание принципов генерации и интерпретации игрового сценария

1.3 Обзор подходов в имитационном моделировании

1.3.1 Принципы продвижения времени

1.3.2 Обзор подходов к моделированию систем

1.4 Вывод

Глава 2. Проектирование подсистемы проведения

2.1 Описание бизнес-процесса

2.2 Проектирование игрового сценария

2.2.1 Трансформация бизнес-процесса

2.2.2 Описание игрового сценария

2.2.3 Хранение сценария

2.3 Проектирование подсистемы проведения

2.3.1 Проектирование архитектуры подсистемы проведения

2.3.2 Описание активного ресурса

2.3.3 Описание алгоритма продвижения времени в модели

2.3.4 Описание алгоритма интерпретации строки ЛСА

2.4 Проектирование приложения

2.4.1 Определение требований к приложению

2.4.2 Выбор программных продуктов

2.4.3 Обеспечение синхронной загрузки данных

2.5 Вывод

Глава 3. Реализация подсистемы проведения

3.1 Генерация веб-приложения с помощью Flexberry Platform

3.2 Реализация страницы игры

3.3 Публикация приложения в сети интернет

3.4 Вывод

Заключение

Библиографический список

Приложение А. Схема бизнес-процесса

Приложение B. Методы активного ресурса

Приложение C. Компоненты клиентского приложения

Приложение D. Метод продвижения времени игрового агента



Введение

На сегодняшний день компьютерные деловые игры являются одним из популярных способов получения знаний [1, 2, 3]. Деловая игра позволяет человеку принимать участие в бизнес-процессах, аналогичных реальным, представляя их в игровом формате [2, 3]. Участник игры имеет возможность принимать решения, связанные с определёнными профессиональными задачами, и получать моделируемые игрой последствия своих решений. Это позволяет участнику игры обучаться новым профессиональным компетенциям.

На данный момент компьютерные деловые игры признаны эффективным средством обучения [1, 2, 3] и всё более широко используются в компаниях и университетах [2, 4]. Например, деловая игра SimulTrain от компании STS предоставляет возможность обучения менеджеров IT-проектов [5], деловые игры серии «Бизнес-курс» используются в учебных заведениях при подготовке специалистов экономического профиля [6], Simformer от UAB Marilana используется предприятиями для тренировки компетенций управления бизнесом [7].

Для того чтобы обеспечить процесс создания деловых игр, способных моделировать бизнес-процессы, необходимо иметь инструменты проектирования и генерации таких игр. Одним из таких инструментов является «студия компетентностных деловых игр» («СКДИ») [8, 9, 10, 11, 12, 13, 14], работа над которой проводится на кафедре информационных технологий в бизнесе в НИУ ВШЭ Пермь. «СКДИ» - это среда проектирования и проведения деловых игр, позволяющая создавать деловые игры на основании схем бизнес-процессов [8].

Представленная работа связана с одной из подсистем «СКДИ» - подсистемой проведения. Эта подсистема предназначена для моделирования игрового сценария, получаемого из исходных бизнес-процессов [8, 10]. Игровой сценарий формируется другой подсистемой «СКДИ» - подсистемой проектирования [8, 11]. Проведение деловой игры достигается за счёт интерпретации игрового сценария подсистемой проведения. Подсистема проведения обеспечивает исполнение игрового сценария, учитывает принятые игроком решения и моделирует последствия выбора игрока [8, 10].

На данный момент в алгоритме игрового сценария учитывается только одна составляющая бизнес-процесса - это тип входных ресурсов. Это ведёт к тому, что в деловых играх, созданных с помощью «СКДИ», не учитывается временной аспект бизнес-процессов. Отсутствие данных о времени исполнения бизнес-процессов ограничивает возможности подсистемы проведения, не позволяя ей моделировать изменения, происходящие с течением времени, в том числе изменения, производимые исполнителями бизнес-процесса.

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

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

Разработку подсистемы проведения деловых игр можно разделить на следующие задачи:

1. Создание игрового сценария:

a. Анализ алгоритма создания игрового сценария в СКДИ.

b. Построение модели бизнес-процесса для игрового сценария.

c. Проектирование схемы игрового сценария с учётом временного аспекта бизнес-процесса.

2. Проектирование подсистемы проведения:

a. Анализ подходов к управлению временем.

b. Выбор подхода к реализации имитационной системы.

c. Описание алгоритма работы имитационной системы.

d. Обеспечение интеграции с подсистемой проектирования в «СКДИ».

3. Реализация прототипа подсистемы проведения:

a. Проектирование архитектуры приложения.

b. Реализация прототипа подсистемы в виде веб-приложения.

c. Апробация игрового сценария.

Необходимо создать игровой сценарий, который создаётся подсистемой проектирования в «СКДИ», включив в него информацию о временном аспекте бизнес-процесса и поведении его исполнителей. Игровой сценарий должен быть основан на заранее выбранном бизнес-процессе.

После этого необходимо выполнить проектирование и реализацию имитационной системы, моделирующую игровой сценарий. Подсистему проведения требуется интегрировать с подсистемой проектирования в «СКДИ». Результатом данной работы является механизм проведения деловых игр, способный исполнять бизнес-процессы с учётом их временного аспекта и действий его исполнителей. Игровые сценарии, создаваемые подсистемой проектирования в «СКДИ», могут быть интерпретированы с помощью реализованного приложения.

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

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

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



Глава 1. Анализ предметной области

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

1.1 Описание архитектуры СКДИ

Студия компетентностных деловых игр представляет собой информационную систему, которая позволяет проектировать и создавать деловые игры на основании схем бизнес-процессов [8]. Она состоит из шести подсистем (рис. 1.1). В рамках данной работы будет рассматриваться подсистема проведения.

Рисунок 1.1. Структурная схема СКДИ

Подсистема проектирования предназначена для того, чтобы превратить исходный бизнес-процесс в интерпретируемый подсистемой проведения игровой сценарий [11]. Сценарий передаётся подсистеме проведения, которая обеспечивает симуляцию деловой игры.

В процессе симуляции, подсистема проведения обрабатывает выбор игрока и меняет ход игрового сценария согласно этому выбору [10]. В результате работы подсистемы проведения, игрок получает результаты симуляции, которые отражают насколько эффективно игрок принимал решения в рамках исходных бизнес-процессов.

1.2 Описание принципов генерации и интерпретации игрового сценария

Игровой сценарий создаётся подсистемой проектирования путём трансформаций исходного бизнес-процесса [11]. В каждой трансформации используется своя модель описания бизнес-процесса. Эти модели разработаны в рамках проекта «СКДИ» и используются при разработке деловой игры [11, 12].

При трансформации бизнес-процесса используются следующие модели (рис. 1.2):

1. Рабочий бизнес-процесс (РБП). Эта модель описывает последовательность операций бизнес-процесса.

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

3. Учебный унифицированный бизнес-процесс (УУБП). Предназначен для описания бизнес-процесса таким образом, чтобы можно было получить его операционную и автоматные модели, необходимые для создания игрового сценария. В отличие от УБП, в УУБП алгоритм бизнес-процесса представлен в виде «карты операций».

Рисунок 1.2. Схема трансформации БП в игровой сценарий

В результате трансформации, подсистема проектирования создаёт игровой сценарий. Игровой сценарий состоит из операционной и автоматной моделей (ОМ и АМ), которые подсистема проведения может интерпретировать [11, 12].

Автоматная модель (АМ) отвечает за выполнение игрового сценария с помощью конечных автоматов [11, 12]. Она представлена в виде строки ЛСА - логической схемы алгоритма, которая позволяет управлять поведением конечного автомата.

Операционная модель (ОМ) предназначена для вывода ресурсов на экран в зависимости от команд, поступающих от автоматной модели [11]. ОМ хранится в реляционной базе данных. Операционная модель (ОМ) состоит из:

1) модели сцены (МС),

2) модели экрана (МЭ),

3) модели ресурсов (МР).

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

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

1) игрок запускает игру,

2) загружается список ресурсов для первой сцены,

3) игрок выбирает любой из загруженных ресурсов и подтверждает свой выбор,

4) система обрабатывает выбор игрока и загружает новый набор ресурсов, формируя новую сцену.

В СКДИ сценарий деловой игры представлен в виде «карты операций» (см. рис. 1.3) [11]. Карта операций содержит в себе несколько элементов:

1) точка принятия решения (ТПР),

2) операция над ресурсами.

ТПР описывает возможный выбор игрока и указывает, какую сцену нужно загрузить в зависимости от выбранного игроком ресурса [11]. Загрузка сцены описывается с помощью блока «операция над ресурсом». Этот блок содержит информацию о том, какие ресурсы будут загружены или удалены из игры.

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

Рисунок 1.3. Пример карты операций

Игровой сценарий позволяет описать активный ресурс (АР). Активный ресурс представляет собой игрового «бота», способного изменять игровые ресурсы на основании заранее заданных правил поведения [14]. «Активный ресурс» используется для создания нестандартных игровых ситуаций.

«Активный ресурс» представляет собой автомат с конечным набором состояний [14]. В зависимости от поступающей команды, «активный ресурс» выполняет определённый набор действий, симулируя поведение исполнителя бизнес-процесса. Симуляция бизнес-процесса, выполняемого активным ресурсом, обеспечивается за счёт интерпретации автоматной модели (АМ), поступающей на вход [11, 14].

1.3 Обзор подходов в имитационном моделировании

1.3.1 Принципы продвижения времени

Процесс моделирования осуществляется путём изменения состояния имитационной модели с течением времени [15, 16]. Время можно разделить на несколько категорий:

1. Физическое время - время в реальной системе.

2. Модельное время - представление физического времени в модели.

3. Процессорное время - время выполнения программы-симулятора на компьютере. Если процессорное время синхронизируется с модельным, говорят о моделировании в реальном времени.

Ключевой задачей имитационной системы является продвижение системы из одного устойчивого состояния в другое [17]. Продвижение модели выполняется по определённым правилам, которые определяют, как состояние изменяется за шаг модельного времени.

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

1) фиксированный шаг,

2) от события к событию.

В первом случае изменение состояния происходит через моделирование фиксированных шагов игрового времени [16, 17]. Имитационная система продвигает игровое время вперёд на размер «шага». При продвижении системы на один «шаг», в системе может возникнуть ряд событий, которые произошли в момент выполнения «шага». К концу шага, все события считаются сработавшими на конец «шага».

Во втором случае моделирование происходит до момента наступления следующего события [16, 17]. Сначала происходит расчёт времени наступления событий, затем происходит поиск события, время наступления которого является самым меньшим. После того, как это событие было найдено, система переходит в новое состояние - на момент времени наступления найденного события.

1.3.2 Обзор подходов к моделированию систем

В имитационном моделировании существует несколько подходов к моделированию систем в зависимости от типа объекта, на основании которого оно осуществляется. Существует 4 подхода к моделированию систем [17]:

1) событийно-ориентированное,

2) процессно-ориентированное,

3) объектно-ориентированное,

4) агенто-ориентированное.

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

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

Таблица 1.1 Сравнительный анализ подходов в имитационном моделировании

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

Для представленной системы был выбран агенто-ориентированный подход, так как он рекомендуется создателями AnyLogic для моделирования бизнес-процессов [15]. При использовании этого подхода исполнитель бизнес-процесса рассматривается в качестве игрового агента.

Агент представляет собой автономный объект, имеющий собственный набор правил поведения, согласно которым он функционирует в системе [18, 19]. Агентное моделирование подразумевает, что конечное состояние системы зависит от поведения агентов [15, 17, 19]. В процессе симуляции агенто-ориентированной модели, каждый из агентов способен изменить состояние системы.

При агентном моделировании имеет место управляющая система («контроллер») [16], которая управляет продвижением времени в имитационной системе (см. рис. 1.4). Управляющая система имеет собственные часы, обозначающие игровое время.

Рисунок 1.4. Взаимодействие агентов и управляющей системы

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

1.4 Вывод

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

Чтобы моделировать поведение исполнителей бизнес-процесса по новому сценарию, необходимо разработать имитационную систему с использованием агентного моделирования с фиксированным шагом игрового времени. В качестве игрового агента необходимо использовать модель «активного ресурса», разработанную в «СКДИ», которая представляет собой модель поведения исполнителя бизнес-процесса. Архитектура имитационной системы должна быть разработана с использованием «контроллера».



Глава 2. Проектирование подсистемы проведения

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

2.1. Описание бизнес-процесса

Было принято решение создать деловую игру на основании бизнес-процесса «Управление командой разработки ПО». Этот БП описывает процесс управления командой разработки ПО в IT организации.

Игрок выступает в роли менеджера команды. Игрок принимает управленческое решение - составить план итерации проекта и распределить задачи в команде. На рис. 2.1 показана IDEF0 диаграмма рассматриваемого бизнес-процесса. Остальные уровни детализации показаны в приложении A.

Рисунок 2.1. IDEF0 диаграмма бизнес-процесса «Управление командой разработки ПО»

Проектируемая деловая игра позволит игроку участвовать в процессе управления проектом. Игра будет симулировать бизнес-процесс «исполнение итерации проекта» (рис. 2.1), который выполняется проектной командой. Проектная команда состоит из: аналитиков, разработчиков, тестировщиков и менеджера команды. Исполнителей каждой категории (кроме менеджера, который является игроком) может быть множество.

Проектная команда работает по плану проекта, назначенным менеджером. Скорость и качество выполнения процесса будет зависеть от навыков сотрудника, которого менеджер включил в план итерации проекта. Таким образом, результаты симуляции БП «Исполнение итерации проекта» (рис 2.2) будут зависеть от выбора игрока.

Рисунок 2.2. Третий уровень декомпозиции БП «Управление командой разработки ПО». Процесс «Исполнение итерации проекта».

Представленный бизнес-процесс «Управление командой разработки ПО» будет использоваться для создания игрового сценария, а также в качестве демонстрационного примера в прототипе подсистемы проведения.

2.2. Проектирование игрового сценария

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

2.2.1 Трансформация бизнес-процесса

Для симуляции бизнес-процесса его необходимо трансформировать в игровой сценарий [11]. Подсистема проектирования производит трансформацию автоматически, но в данной работе процесс трансформации будет описан вручную, чтобы учесть временной аспект, который ещё не учитывается подсистемой проектирования. Трансформация БП в игровой сценарий состоит из нескольких этапов:

1) построение исходного бизнес-процесса,

2) трансформация в рабочий бизнес-процесс (РБП),

3) трансформация в унифицированный учебный БП (УУБП),

4) трансформация в карту операций,

5) построение ЛСА и заполнение базы данных.

Схему игрового сценария можно представить в виде рабочего бизнес-процесса (РБП) (рис. 2.3). Представленный рабочий бизнес-процесс позволяет описать алгоритм выполнения операций и бизнес-условия, способные изменить ход игры.

Рисунок 2.3. Рабочий БП «Управление командой разработки ПО»

Построенный РБП начинается с операции «выбрать план итерации проекта». Следующие три операции раскрывают БП «исполнение итерации проекта» (рис. 2.3). После этого в схему добавляется бизнес-условие, определяющее, осталось ли время на исполнение проекта. Бизнес-условие осуществляет проверку в конце каждой итерации. Игра завершается, когда время на исполнение проекта заканчивается.

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

Третий этап трансформации - в учебный унифицированный бизнес-процесс (УУБП). УУБП рассматриваемого бизнес-процесса представлен на рис. 2.4.

Рисунок 2.4. Алгоритм учебного унифицированного БП (УУБП) «Управление командой разработки ПО»

На этом этапе добавляется информация об исполнителях операций бизнес-процесса. Исполнители БП обозначаются как «активные ресурсы». На рис. 2.4 они обозначены как «АР», что значит «Активный ресурс».

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

Четвертый этап трансформации - в карту операций. Карта операции является последним этапом трансформации перед формированием итогового сценария. Чтобы учесть аспект времени, в карту операций были добавлены следующие данные (рис. 2.5):

1) время выполнения операции,

2) затраты на исполнение операции,

3) код процесса,

4) код исполнителя бизнес-процесса.

Рисунок 2.5. Карта операций для БП «Управление командой разработки ПО»

Новые данные позволяют задать, сколько времени будет работать исполнитель, и какую часть бюджета будет тратить каждый из них. Код исполнителя бизнес-процесса позволит указывать не только тип исполнителя, но и его «экземпляр». В частности, это позволит закрепить несколько исполнителей одного типа (например, аналитиков) за разными операциями.

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

2.2.2 Описание игрового сценария

Карта операций является неполным описанием игрового сценария. Чтобы полностью описать игровой сценарий, необходимо указать используемые в бизнес-процессе ресурсы и его исполнителей. На основании бизнес-процесса (см. рис. 2.1 - 2.2) и карты операций (см. рис. 2.5) был составлен список игровых ресурсов (табл. 2.1) и игровых агентов (экземпляров активных ресурсов) (табл. 2.2).

Атрибуты ресурса видимы игроком и используются им для принятия решений. Например, игрок может заметить, что сотрудник «Дарья» имеет низкий навык аналитика и низкую зарплату 150р/ч. Игрок может принять решение использовать план проекта «недорогой», чтобы сэкономить бюджет на текущей итерации, поручив работу недорогому сотруднику. Таким образом, игрок может принимать решения на основании имеющихся игровых ресурсов и их атрибутов.



Список игровых ресурсов

Код		Тип ресурса	Название ресурса	Атрибуты ресурса
R1		План проекта	План проекта «Недорогой»	Описание: Команда недорогих специалистов. Характеристика: Низкая скорость выполнения проекта. Минимум затрат.
R2		План проекта	План проекта «Сбалансированный»	Описание: Команда обычных специалистов. Характеристика: Скорость выполнения проекта ниже среднего. Затраты невысокие.
R3		План проекта	План проекта «Быстрый»	Описание: Команда профессионалов. Характеристика: Высокая скорость выполнения проекта. Затраты очень высокие.
R0		Бюджет	Бюджет проекта	10000р.

Экземпляры активных ресурсов

Код	Активный ресурс	Название ресурса	Атрибуты экземпляра АР
AR1.1	Аналитик	Дарья	Навык аналитика: 3 Стоимость: 150р/ч
AR1.2	Аналитик	Андрей	Навык аналитика: 6 Стоимость: 350р/ч
AR1.3	Аналитик	Петр	Навык аналитика: 4 Стоимость: 200р/ч
AR2.1	Разработчик	Павел	Навык разработчика: 5 Стоимость: 200р/ч
AR2.2	Разработчик	Александр	Навык разработчика: 7 Стоимость: 300р/ч
AR2.3	Разработчик	Мария	Навык разработчика: 3 Стоимость: 120р/ч
AR3.1	Тестировщик	Александра	Навык тестировщика: 10 Стоимость: 450р/ч
AR3.2	Тестировщик	Владислав	Навык тестировщика: 7 Стоимость: 300р/ч
AR3.3	Тестировщик	Татьяна	Навык тестировщика: 5 Стоимость: 220р/ч

2.2.3 Хранение сценария

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

1) операции основного бизнес-процесса,

2) операции бизнес-процесса активного ресурса,

3) игровые ресурсы и их участие в операциях бизнес-процессов,

4) игровые агенты (активные ресурсы).

Таблицы «Бизнес-процесс» и «Операция» предназначены для описания операций основного бизнес-процесса. Таблица «РесурсВОперации» предназначена для связи операций с ресурсами, которые в них участвуют. Игровые ресурсы имеют свой тип и атрибут (таблицы «ТипРесурса» и «АтрибутРесурса»). Таблицы «БизнесПроцессАР» и «ОперацияАР» описывают бизнес-процесс активного ресурса. Таблицы «АктивныйРесурс», «АтрибутАР» описывают активный ресурс. Таблица «ЭкземплярАР» описывает игровых агентов, выполняющих бизнес-процесс активного ресурса.

Рисунок 2.6. Схема базы данных для хранения игрового сценария

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

2.3 Проектирование подсистемы проведения

При проектировании подсистемы проведения используется подход агенто-ориентированного имитационного моделирования. Архитектура подсистемы проектируется с использованием моделей, разработанных в «СКДИ».

2.3.1 Проектирование архитектуры подсистемы проведения

Согласно В.В. Окольнишникову[16], для реализации механизма продвижения времени в имитационной системе при использовании агентного моделирования, необходимо разделить игровых агентов и управляющий модуль. Управляющий модуль должен управлять игровыми агентами и продвигать общее игровое время. Соответственно, подсистема проведения деловых игр состоит из управляющего модуля («контроллера») и игровых агентов (см. рис. 2.7).

Рисунок 2.7. Описание работы управляющей системы и агентов

Симуляция деловой игры достигается за счёт моделирования поведения агентов. Управляющая система («контроллер») отвечает за:

1) интерпретацию строки ЛСА,

2) активацию игровых сцен,

3) продвижение игрового времени,

4) управление игровыми агентами.

Контроллер интерпретирует игровой сценарий, переходя к нужной сцене и активируя агентов. После активации агентов, контроллер осуществляет продвижение времени на n единиц. Алгоритм работы контроллера указан на рис. 2.8.

Рисунок 2.8. Алгоритм работы управляющей системы («контроллера»)

Активированные агенты исполняют полученный процесс в процессе продвижения времени контроллером (рис 2.9). В момент, когда все агенты выполнили порученные им процессы, контроллер переходит к следующей команде ЛСА.

Рисунок 2.9. Взаимодействие контроллера и активных ресурсов

На каждом шаге игрового цикла (см. рис. 2.8), контроллер может вызвать один из методов активных ресурсов (рис. 2.10). Алгоритмы методов активного ресурса указаны в приложении B. Список возможных методов активного ресурса:

1. schedule - метод, переводящий активный ресурс в рабочее состояние.

2. step - метод, продвигающий время активного ресурса на 1 ед вперед.

3. completed - метод, сообщающий контроллеру о завершении работы активного ресурса.

Рисунок 2.10. Пример: Завершение процесса активным ресурсом

Атрибуты ресурсов изменяются агентами при каждом шаге игрового цикла. В момент, когда необходимо продвинуть модель на 1 ед. игрового времени, управляющая система выбирает агентов, которые должны в течение моделируемого «шага» исполнить процесс. Затем происходит исполнение процесса агентом. В момент продвижения времени, агент симулирует исполнение процесса, изменяя игровые ресурсы согласно правилам, указанным в сценарии.

При переходе к следующей сцене, контроллер передаёт операции активным ресурсам, переводя их в состояние «занят». «Занятый» активный ресурс обеспечивает симуляцию процесса, который был ему передан. Симуляция процесса происходит в соответствие с правилами процесса.

2.3.2 Описание активного ресурса

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

1) очередь процессов агента,

2) часы агента,

3) состояние агента (занят или свободен),

4) текущий процесс агента,

5) характеристики агента.

Рисунок 2.11. Модель активного ресурса

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

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

Каждый «шаг» активного ресурса изменяет атрибуты текущего процесса, которым он управляет на данный момент. Правила, по которым изменяются атрибуты, указаны в игровом сценарии. В конце каждого цикла выполняется проверка, нужно ли завершать процесс.

2.3.3 Описание алгоритма продвижения времени в модели

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

Рисунок 2.12. Диаграмма последовательности «Продвижение времени имитационной системы на 1 шаг»

После того, как процесс завершил свою работу, выполнение блока симуляция продолжается и выполнение переходит к следующему процессу. Таким образом, блок продвинет время на 1 шаг, запустив симуляцию процессов по порядку. Количество шагов задаётся пользователем.

Процесс симуляции начинается с запроса на запуск симуляции. Управляющая система получает запрос на продвижение игрового времени на 1 шаг. После этого управляющая система начинает обращение к активным ресурсам. Порядок обращения к агентам зависит от порядка бизнес-процессов, указанных в сценарии (рис 2.13).

Каждый бизнес-процесс исполняется каким-либо активным ресурсом, поэтому в момент исполнения определённого процесса, вызывается метод соответствующего активного ресурса, который управляет рассматриваемым процессом.

Рисунок 2.13. Схема продвижения времени активного ресурса (метод step)

2.3.4 Описание алгоритма интерпретации строки ЛСА

Управляющий модуль должен использовать строку ЛСА для того, чтобы управлять игровыми агентами. Используя интерпретатор строки ЛСА, управляющий модуль сможет получать команды для того, чтобы двигаться в соответствии с алгоритмом бизнес-процесса и изменять состояние агентов.

На рис. 2.14 показан алгоритм перехода к следующей операции. Операция, которая должна выполниться после текущей, получена от интерпретатора ЛСА, который разбирает строку ЛСА текущего бизнес-процесса.

Рисунок 2.14. Действие пользователя «Перейти к следующей операции»

Строка ЛСА может состоять из следующих символов:

1. Н оператор начала алгоритма (S).

2. К оператор конца алгоритма (F).

3. Р условный переход (pR1).

4. А управляющее воздействие. (^2)

5. щ безусловный переход (w).

6. ^ начало перехода (^).

7. v окончание перехода (.).

Строка ЛСА для сценария, рассмотренного в разделе 2.2, выглядит следующим образом: S pR1^1 pR2^2 pR3^3 .1 ARP1ARP2ARP3 w^4 .2 ARP4ARP5ARP6 w^4 .3 ARP7ARP8ARP9 w^4 .4 F.

Каждый символ строки ЛСА относится к какой-либо команде, которая может быть распознана контроллером. Список команд, распознаваемых контроллером:

1. «Start». Команда начала разбора бизнес-процесса

2. «Choice» + массив игровых ресурсов. Позволяет игроку выбрать один из предложенных ресурсов.

3. «Simulate» + код операции или бизнес-процесса. Запускает процесс симуляции бизнес-процесса. БП исполняется игровыми агентами.

4. «MoveTo» + номер точки. Перемещает контроллер на позицию разбора, соответствующую номеру точки.

5. «Finish». Завершает разбор бизнес-процесса.

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

2.4 Проектирование приложения

2.4.1 Определение требований к приложению

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

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

1. Фреймворк на стороне сервера («back-end»), обеспечивающий доступ к объектам базы данных.

2. Фреймворк на стороне клиента («front-end»), позволяющий реализовать симуляцию сценария и отобразить результаты на экране.

3. Фреймворк объектно-реляционного представления данных (ORM),

4. СУБД - система управления базами данных.

5. Удалённый сервер баз данных для работы с базой данных через сеть интернет.

2.4.2 Выбор программных продуктов

Для создания прототипа приложения подсистемы проведения была выбрана CASE-платформа Flexberry, разрабатываемая компанией «ИВС». Выбор был сделан в пользу этой платформы, так как она позволяет генерировать код веб-приложения на основании схемы базы данных, значительно ускоряя процесс разработки. Кроме того, платформа предоставляет собственную технологию ORM, позволяющую разработчику работать в терминах классов, без необходимости использования таблиц данных.

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

1) Ember.JS / ASP.NET Web Api в качестве клиентского фреймворка.

2) PHP / Java / ASP.NET Web Api в качестве серверного фреймворка.

3) Microsoft SQL Server / Postgres SQL / Oracle в качестве СУБД.

Ember.JS был выбран в качестве клиентского фреймворка, так как он является фреймворком одностраничных приложений (SPA - single page application), позволяет гибко настроить пользовательский интерфейс и обеспечивает удобство в работе с объектами.

В качестве программных продуктов, работающих на стороне сервера, был выбраны ASP.Net Web Api и Microsoft SQL Server, так как разработчик приложения имеет опыт работы с языком программирования C# и СУБД MS SQL Server.

Таким образом, в приложении будут использоваться следующие средства:

1. Ember.JS - «front-end» фреймворк.

2. Сервер ASP.NET - «back-end» фреймворк.

3. Flexberry ORM.

4. Microsoft SQL Database - СУБД.

5. Azure Microsoft SQL Database Server - удалённый сервер баз данных.

База данных приложения будет расположена на удалённом сервере Microsoft Azure. Это позволит обращаться к БД через сеть интернет и позволит взаимодействовать с ней другим разработчикам проекта «СКДИ». Это также позволит иметь возможность загрузить клиентское приложение на удалённый сервер, полностью освободившись от необходимости запускать подсистему в локальной сети.

В результате, схема взаимодействия компонентов приложения будет иметь вид, указанный на рис. 2.15. Игрок взаимодействует с клиентским приложением Ember.JS, участвуя в игровом процессе. Клиентское приложение получает команды пользователя и в случае необходимости получает данные от сервера ASP.Net с помощью веб-запросов.

Рисунок 2.15. Схема взаимодействия компонентов приложения

Сервер ASP.Net использует REST API, ранее сгенерированный платформой Flexberry, чтобы интерпретировать запросы клиентского приложения. В ответ на запрос от приложения Ember.JS, сервер ASP.Net получает информацию об игровых ресурсах с помощью Flexberry ORM, и возвращает результат веб-запроса обратно клиенту. Пример запроса на загрузку и запуск бизнес-процесса указан на рис. 2.16.

Рисунок 2.16. Обработка команды пользователя «Запуск бизнес-процесса»

2.4.3 Обеспечение синхронной загрузки данных

Flexberry ORM использует асинхронные запросы к серверу для получения объектов из базы данных. Это означает, что при проектировании алгоритмов интерпретатора строки ЛСА, необходимо обрабатывать асинхронные запросы Flexberry ORM и выполнять действия синхронно, то есть только после завершения загрузки объекта из базы данных.

На рисунке 2.17 приведён пример необработанной асинхронной загрузки объекта. В момент, когда команда ЛСА на загрузку БП была обработана (операция 1.1 на рис. 2.17), интерпретатор использует асинхронную функцию Flexberry ORM для загрузки объекта. В случае если асинхронный запрос не будет обработан, интерпретатор продолжит выполнение функции, не дожидаясь окончания загрузки.

Рисунок 2.17. Пример необработанной асинхронной загрузки объекта

Следовательно, необходимо обрабатывать асинхронные запросы на загрузку объектов во избежание ошибок. Существует два способа обработки асинхронных запросов в JavaScript:

1) вспомогательный класс «Promise»,

2) конструкция async/await.

Так как Ember.JS не поддерживает использование конструкций async/await, в проектируемом приложении необходимо использовать библиотеку RSVP.Promise для обработки асинхронных запросов. В таком случае в приложении не будет возникать ошибок, связанных с незагруженными объектами (см. рис. 2.18). На представленном рисунке показан пример обработанного асинхронного запроса.

Рисунок 2.18. Пример обработанной асинхронной загрузки объекта

2.5 Вывод

В итоге, был использован метод агентного моделирования при проектировании архитектуры подсистемы проведения. Алгоритм продвижения времени системы был описан с учётом выбранного метода моделирования.

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

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



Глава 3. Реализация подсистемы проведения

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

3.1 Генерация веб-приложения с помощью Flexberry Platform

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

Перед генерацией приложения необходимо создать диаграмму классов UML. Во Flexberry была построена диаграмма классов, аналогичная той, что была построена на этапе проектирования игрового сценария (см. рис 2.6, рис 3.1).

Рисунок 3.1. Диаграмма классов подсистемы проведения

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

Рисунок 3.2. Настройка представления класса «Ресурс»

Формы редактирования и просмотра списка объектов были автоматически сгенерированы для каждого класса на основании заданных представлений. Например, на рис. 3.3 показана форма редактирования игровых ресурсов.

Рисунок 3.3. Редактирование ресурса «Бюджет проекта»

При генерации приложения было создано 15 моделей объектно-реляционного представления (ORM), которые могут быть использованы для загрузки данных из БД (см. рис 3.4). Каждая модель представлена в виде объекта Ember.Object, хранящего информацию о:

1) представлениях модели, заданных с помощью Flexberry Designer,

2) загружаемых вместе с представлением атрибутах,

3) правилах валидации модели, несоблюдение которых не позволит сохранить модель.



Рисунок 3.4. Структура папок приложения Ember.JS. Папка с моделями объектно-реляционного представления (ORM).

В результате генерации приложения, было получено следующее:

1) клиентское приложение Ember.JS,

2) серверное приложение ASP.NET Web API,

3) база данных Microsoft SQL Server.

Клиентское и серверное приложения были запущены и настроены для работы в локальной сети. Архитектура сгенерированного веб-приложения соответствует рис. 2.15. Серверное приложение успешно принимает веб-запросы от клиента.

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

3.2 Реализация страницы игры

Внешний вид страницы был создан с помощью шаблонизатора Handlebars, который является частью фреймворка Ember.JS. Использование шаблонизатора позволило динамически загружать и отображать игровые ресурсы. Для каждого из ресурсов был создан свой «компонент». Компоненты используются для настройки внешнего вида отдельных элементов модели.

Всего в приложении было создано 4 компоненты:

1) Arinstance-info - отображает активных игровых агентов.

2) Resource-choice - отображает игровой ресурс, который пользователь может выбрать.

3) Resource-info - отображает игровой ресурс, который не может быть выбран пользователем.

4) Process-info - информация об активном процессе (для страницы отладки).

Ember.JS использует концепцию DDAU - «данные вниз - действия вверх». Это означает, что каждый компонент должен получать данные от своего родителя. Например, в шаблоне «arinstance-info» это реализовано следующим образом. Внутрь компоненты поступает модель: экземпляр активного ресурса разработчик «Мария» (в табл. 3.1 - это «arimodel»). Компонент, получив данные, отображает их в соответствии со своим шаблоном (табл 3.1).

Описание компоненты «Экземпляр АР»

Код вызова компоненты	Код компоненты	Результат работы
{{arinstance-info arinstance=arimodel showAmount=true}}	<div class="header"> {{arinstanceType.name}} {{arinstance.name}} </div> <div class="description"> {{#each attributes as |attribute|}} <p>{{attribute.name}}: {{attribute.amount}}</p> {{/each}} </div>

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

Загрузка игровых ресурсов на сцену производится с помощью инструмента Flexberry Query, который позволяет обращаться к серверу ASP.NET с установленным пакетом Flexberry ORM. Запрос строится с помощью специального языка запросов. Рассмотрим функцию загрузки ресурса на сцену (см. рис. 3.5).

Перед началом загрузки ресурса, создаётся условие SimplePredicate, в котором указывается, что необходимо получать только те ресурсы, которые имеют указанный код. Затем строится запрос на получение ресурса из БД с помощью функции Query.Builder. Query.Builder содержит информацию о представлении, по которому необходимо совершить загрузку ресурса (ResourceE), о типе загружаемой модели (n-i-b-g-resource) и о наборе ограничений (byCode).

loadResource(code) { var self = this; //Сохраняем контекст //Строим запрос: var byCode = new SimplePredicate('code', Query.FilterOperator.Eq, code); let builder = new Query.Builder(this.get('store')) .from('n-i-b-g-resource') .selectByProjection('ResourceE') .where(byCode); //Вызываем запрос (асинхронный метод): return self.get('store').query('n-i-b-g-resource', builder.build()) .then((result) => { let resource = result.get('firstObject'); console.log('Загружен ресурс: ' + code); return resource; }); },

Рисунок 3.5. Метод загрузки ресурса из БД

После этого сформированный запрос на получение ресурса вызывается асинхронно. Согласно требованиям, асинхронный запрос должен быть обработан с помощью класса Promise. Это выполняется с использованием «callback-метода» .then(), который вызывается после завершения выполнения асинхронного запроса. Результат выполнения функции - это класс Promise, возвращающий загруженный ресурс. Загрузка всех остальных объектов выполняется аналогично.

Таким образом, была реализована главная страница игры (рис 3.6). На экране отображается игровое время, бюджет и список активных игровых агентов (активных ресурсов в состоянии «занят»). Игра начинается по кнопке «запустить процесс».

Страница игры

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

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

Модальное окно выбора ресурса

Продвижение игрового времени происходит во время разбора строки ЛСА. В случае, если существует хотя бы один активный игровой агент, метод продвижения времени выполнится у всех игровых агентов (рис. 3.8). Алгоритм продвижения времени игровых агентов указан в приложении D.