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

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

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

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

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, позволяющую разработчику работать в терминах классов, без необходимости использования таблиц данных.