Компетентностная деловая игра
Введение
В последние годы популярным методом получения знаний являются деловые игры (ДИ). В частности, компьютерные деловые игры являются одним из наиболее эффективных методов активного обучения и широко применяются как в учебном процессе в системе высшего и среднего образования, так и в корпоративном обучении [1]. Деловые игры имитируют реальную обстановку, обеспечивают условия, максимально приближенные к реальным, для лучшего восприятия информации, оптимального построения логики и решений и получения удовлетворительных результатов в итоге [2]. Такой способ освоения материала является довольно интересным, так как позволяет соотносить все процессы игры с реальным миром и, сопоставляя их с реальными ситуациями, принимать решения.
Компьютерная деловая игра представляет собой учебно-тренинговую компьютерную систему, которая используется как при подготовке бакалавров, магистров и специалистов различных профилей, так и для обучения и повышения квалификации персонала. Обычно деловые игры применяют в сфере экономики и менеджмента, к примеру, компьютерные деловые игры серии «Бизнес-Курс» [3, 4], «Никсдорф Дельта» компании «ГРЕЙТ» [5, 6], игра «Factory» компании Team Training [7], деловые игры BI TO BI [8] и др. Эти игры направлены на развитие совокупности профессиональных навыков и качеств руководителей и сотрудников компаний.
В рамках данной работы была выполнена работа по проектированию и разработке прототипа подсистемы проведения деловой игры (ППДИ) студии компетентностных деловых игр (СКДИ). СКДИ является инструментальной средой для проектирования и проведения деловых игр [1, 2, 9, 10, 11]. В рамках СКДИ была разработана модель проведения деловой игры [9], которую необходимо реализовать в виде программного продукта. Была спроектирована архитектура ППДИ и разработан ее прототип. Также был спроектирован и разработан прототип модуля ППДИ - «Активный ресурс» (АР) [12, 13], который выступает в роли исполнителя и выполняет действия, заложенные в его сценарий.
Работа подсистемы проведения деловых игр заключается в следующем: при проведении деловой игры (ДИ) игрок выбирает различные ресурсы, затем выполняется определенная операция бизнес-процесса (БП). После выполнения очередной операции система должна предложить игроку доступные ресурсы. В процессе игры необходимо следить за тем, чтобы очередная операция БП выполнялась строго в хронологическом порядке. Если же текущий БП сначала должен получить ответ от модуля «Активный ресурс», то система сначала должна дождаться этого ответа и только потом в зависимости от него предложить доступные для выполнения очередной операции БП ресурсы. Очередная операция может оказаться доступной для выполнения, когда все ресурсы, необходимые для ее осуществления, доступны пользователю для выбора, и операция должна выполниться до наступления окончания времени, выделенного на операцию.
Прототип, разработанный на данный момент, позволяет игроку выбрать ресурсы для выполнения очередной операции БП, после чего система выполняет соответствующие действия согласно логической схеме алгоритма (ЛСА), но при этом не учитывает хронологический порядок бизнес-процессов. Модели бизнес-процессов, используемые при проектировании ДИ, также не учитывают фактор времени. Исследуемой в данной работе проблемой является отсутствие при проведении деловой игры настройки времени выполнения операций бизнес-процесса и возможности моделирования выполнения операций во времени. Разрабатываемый в рамках данной работы продукт позволит решить этот вопрос посредством внедрения механизма синхронизации времени, который будет контролировать процесс своевременного выполнения всех операций, следовательно, тема работы является актуальной.
Помимо структуры подсистемы проведения ДИ и алгоритмов ее исполнения в текущей работе описан принцип распределенного имитационного моделирования (ИМ), основные подходы к управлению временем в таком моделировании. Также в работе проанализированы некоторые алгоритмы реализации распределенной имитационной модели, выполнено проектирование ППДИ с использованием распределенного ИМ и описана реализация прототипа подсистемы с учетом выполненного проектирования.
Теперь можно выделить объект и предмет исследования. Объектом исследования является взаимодействие пользователя с подсистемой проведения деловых игр, предметом исследования - реализация взаимодействия пользователя с подсистемой с использованием метода распределенного ИМ.
Целью выпускной квалификационной работы является проектирование и разработка подсистемы проведения деловых игр, используя метод распределенного имитационного моделирования.
Для достижения поставленной цели необходимо решить следующие задачи:
.Анализ существующих на данный момент алгоритмов для проектирования и проведения ДИ в студии компетентностных деловых игр.
.Анализ алгоритмов и подходов к управлению временем, реализующих распределенное имитационное моделирование.
.Формулировка требований к подсистеме проведения ДИ.
.Разработка алгоритмов работы ППДИ.
.Проектирование ППДИ с использованием диаграмм.
.Проектирование моделей бизнес-процессов для построения сценария, выполняющегося ППДИ и разработка контрольного примера.
.Проектирование ЛСА, реализующей сценарий ДИ, с учетом исполнения соответствующего БП во времени.
.Проектирование базы данных (БД) подсистемы проведения ДИ.
.Проектирование форм.
.Разработка прототипа ППДИ.
.Тестирование ППДИ с использованием разработанного контрольного примера.
Для выполнения данных задач были использованы следующие методы: метод функционального моделирования, объектно-ориентированное проектирование, объектно-ориентированное программирование, имитационное моделирование.
Практическая значимость работы заключается в модификации процесса проведения деловой игры. Разрабатываемая система будет учитывать порядок выполнения операций бизнес-процессов во времени, что позволит приблизить моделируемые процессы в ППДИ к реальным и поможет при дальнейшей доработке студии компетентностных деловых игр.
Результатом работы является прототип ППДИ, который позволяет провести деловую игру с учетом времени выполнения операций.
1.Анализ предметной области
В самом начале работы требуется проанализировать область, представляющую интерес в текущей работе. В данной главе описана общая структура студии компетентностных деловых игр, в частности подсистемы проведения, а также выполнен обзор алгоритмов распределенного имитационного моделирования.
.1 Описание структуры СКДИ
Компетентностная деловая игра - это информационная система, целью которой является получение определенного уровня профессиональных компетенций в процессе реализации сценариев, определяемых моделями бизнес-процессов предметной области. Студия компетентностных деловых игр выступает инструментарием для разработки и проведения таких деловых игр. Сотрудниками кафедры информационных технологий в бизнесе, в рамках которой разрабатывается СКДИ, был предложен многомодельный подход к разработке такой инструментальной среды [2]. Структурная схема СКДИ представлена на рисунке 1.1.
Рисунок 1.1. Структурная схема СКДИ
В рамках данной работы будут рассмотрены подсистемы проектирования и проведения. Подсистема проектирования ориентирована на разработку сценариев деловых игр, моделей предметных областей, на базе которых выполняются сценарии, также с помощью подсистемы проектирования могут создаваться учебно-методические материалы для проведения игр и контрольно-измерительные материалы. Исходные данные для подсистемы проектирования представляет модель предприятия в неформализованном виде [2].
После проектирования деловой игры формализованная модель данных должна быть наполнена самими данными, что производится в рамках подсистемы проведения [14]. В подсистеме проведения происходит выполнение сценария деловой игры и создается деловая обстановка, в которой игрок принимает решения, тем самым формируя определенный набор компетенций. Деловая обстановка представляет собой совокупность различных ресурсов, доступных для игрока. При проведении деловой игры игрок выбирает различные ресурсы, после чего происходит выполнение определенной операции бизнес-процесса. Дальше система предлагает игроку доступные для выполнения очередной операции БП ресурсы.
Некоторые существующие в игре ресурсы могут играть активную роль (оппонент или активный ресурс), работа которых осуществляется в отдельном модуле. Модуль «Активный ресурс» выступает в роли исполнителя, т.е. исполнителем может быть не только игрок, поскольку существуют такие действия, которые происходят в результате совершения каких-либо других действий. АР выполняет операцию как отдельный участник на основе существующих данных либо запрашивая дополнительную информацию у игрока [12].
Как подсистема проведения ДИ, так и модуль «Активный ресурс» предполагает наличие автоматной и операционной моделей (АМ, ОМ). В АМ происходит выполнение алгоритма, заложенного в сценарий ДИ. В качестве такой модели используется полученная на этапе проектирования логическая схема алгоритма. В ОМ формируется деловая обстановка на основе команды, поступающей из АМ. ОМ представляет собой множество наборов, включающих модель экрана, модель сцены и модель ресурсов (или Ресурсы) [13].
Алгоритм выполнения операции, включающий определенные в [12] функции АМ и ОМ, следующий:
.Пользователь выбирает ресурсы.
.Операция выполняется:
.1.ОМ формирует условие, отвечающего действиям пользователя, для перехода к следующей сцене.
.2.ОМ отправляет условие АМ.
.3.АМ принимает условие, выполняет запрос к БД.
.4.АМ выделяет команду из ЛСА.
.5.АМ отправляет команду ОМ.
.ОМ получает команду, выполняет запрос к БД, ищет модель сцены.
.ОМ выбирает из БД ресурсы, соответствующие текущей модели сцены.
.ОМ загружает ресурсы в модель экрана (выводит на экран).
Также в работе [12] были определены функции, выполняемые активным ресурсом:
.Загрузка ЛСА из БД.
.Выделение команды из ЛСА (выполняется автоматной моделью).
.Выбор модели сцены и ресурсов (диалоговых окон) по команде (выполняется ОМ).
.Вывод на экран с помощью МЭ ресурсов из БД, соответствующих модели сцены (выполняется ОМ).
.Получение ответов игрока (выполняется ОМ).
Однако в системе нельзя задать время выполнения операций и смоделировать выполнение операций во времени, т.е. все операции выполняются в логическом порядке (согласно ЛСА), но без учета времени. В рамках данной работы предполагается применить распределенную имитационную модель к существующим алгоритмам в СКДИ, что поможет приблизить деловую обстановку в игре к реальной.
.2 Анализ моделей бизнес-процессов СКДИ
Чтобы применить распределенную имитационную модель в СКДИ, необходимо проанализировать разработанные в рамках СКДИ алгоритмы, а именно языки моделей бизнес-процессов, которые не отображают временные характеристики БП на данный момент. В СКДИ используются понятия трех моделей бизнес-процессов: реального (существующего на предприятии), унифицированного (промежуточного между реальным и учебным) и учебного унифицированного (на котором можно обучать). В рабочем (или реальном) бизнес-процессе (РБП) имеются определенные действия, их исполнители и различные ресурсы, необходимые для осуществления действий и получаемые в результате реализации действий. Пример диаграммы IDEF0 для абстрактного РБП (см. рис. 1.2):
Рисунок 1.2. Пример диаграммы IDEF0 для РБП
Здесь D1...D4 - это действия (или операции), осуществляемые в бизнес-процессе, R1…R6 - ресурсы на входе и выходе действий, U1, U2, U3 - управление действиями, I1, I2 - исполнители действий, M1, M2 - механизмы (табл. 1.1).
Таблица 1.1. Описание диаграммы IDEF0
ВходДействиеВыходИсполнительR1, R2D1R3I1R3D2R4I1R4D3R5I2R5D4R6I1
Выполняемые на предприятиях реальные бизнес-процессы не могут использоваться как модели при проектировании деловых игр, поскольку они сложны, могут содержать ошибки при неправильной организации работы предприятия, к тому же решающие одну задачу БП на однотипных предприятиях могут отличаться. Ввиду наличия таких фактов вводится понятие модели унифицированного бизнес-процесса (УБП), в котором будут отражены существенные независимые характеристики реальных бизнес-процессов предприятий [2].
Модель УБП состоит из двух частей «Последовательность операций» и «Операция». «Последовательность операций» представляет собой строгий алгоритм выполнения операций, который можно представить в виде блок-схем. Для построения такой модели необходимо выделить операции исполнителя. «Операция» - это модель, которая описывает каждый элемент УБП детально.
Рисунок 1.3. Блок-схема основной программы
Рисунок 1.4. Модель операции для операции 1
На основе УБП строится модель учебного унифицированного бизнес-процесса, которая представляет собой модель карты операций - дерева, состоящего из множества операций и множество точек принятия решений (ТПР). ТПР позволяет перейти от одной операции к другой, причем из одной точки можно перейти к нескольким операциям (рис. 1.5). Таким образом, получается иерархическая структура, каждая ветвь которой это возможный путь в ДИ [11].
Рисунок 1.5. Пример карты операций
Как видно из этих моделей, языки не отражают время операций, в связи с чем требуется изменение языков данных моделей с учетом времени. Для добавления времени в модели БП было решено использовать алгоритмы распределенного имитационного моделирования.
.3 Обзор имитационного моделирования
В имитационном моделировании выделяют три вида времени: физическое, модельное и процессорное. Физическое время характеризует процессы в реальной системе; модельное время отображает физическое время в виртуальное, использующееся имитационной системой. В зависимости от требований к процессу это время может идти как быстрее физического, так и медленнее. Процессорное время - это фактическое время выполнения модели на компьютере [15].
На данный момент существует два направления решения проблемы управления временем в имитационном моделировании - это последовательное и распределенное ИМ [16, 17]. В последовательном ИМ все три понятия времени соотносятся между собой однозначно, что касается распределенного моделирования, то процесс протекания времени является более сложным из-за возникающих парадоксов времени [15]. Ниже, в таблице 1.2, представлен сравнительный анализ последовательного и распределенного ИМ:
Таблица 1.2. Сравнительный анализ последовательного и распределенного ИМ
Характеристика / составляющиеПоследовательное ИМРаспределенное ИМКомпонент моделированияОбъект (процесс)Логический процессСписок событийЦентрализованный (в управляющей программе)Локальный (в логическом процессе)Часы модельного времениГлобальные (в управляющей программе)Локальные (в логическом процессе)Программа синхронизации компонентов моделированияУправляющая программаКоммуникационная подсистемаВзаимодействие программы синхронизации с компонентами моделированияВзаимодействие управляющей программы с объектами посредством клиент-серверного подходаВзаимодействие логических процессов с коммуникационной системой с помощью интерфейсаВзаимодействие между компонентами моделированияНетОбмен сообщениями между логическими процессамиСкорость выполненияпри моделировании сложных системНижеВышепри моделировании несложных системВышеНижеСложность реализацииПростоСложно (т.к. необходима синхронизация между логическими процессами)Эффективность реализацииВыше при моделировании несложных системЗависит от алгоритма синхронизации модельного времени
Развитие распределенного ИМ осуществляется по двум направлениям: параллельное дискретное событийно-ориентированное моделирование PDES (Parallel Discrete Event Simulation) и объединение разнородных систем моделирования.
В первом случае имитационная модель представляет собой совокупность логических процессов, которые обмениваются сообщениями друг с другом. ЛП распределяются по вычислительным узлам вычислительной системы и обмениваются сообщениями, используя линии связи между ее узлами. Однако при переносе системы на другую платформу могут возникнуть проблемы, т.к. имитационные модели тесно связаны со средой, для которой они разрабатывались [18, 19].
Второе направление (ИМ высокого уровня) описывает программные средства, которые позволяют объединить уже готовые системы имитации для проведения распределённого имитационного эксперимента. Задача состоит в том, чтобы создать окружение для взаимодействия уже ранее созданных имитационных моделей. В настоящее время широко используется такой подход как HLA (High Level Architecture или «Архитектура высокого уровня») [16, 18, 19], который в [16] описан как новый этап развития ИМ.
В таком имитационном моделировании его компонентами являются не объекты как в последовательном ИМ, не логические процессы как в параллельном или распределенном ИМ, а «федераты», которые объединяются в «федерации». Федераты одной федерации могут быть разнородными (это могут быть имитационные модели, тренажеры, программа для сбора данных и т.д.). Взаимодействие федератов и их исполнение в едином модельном времени происходит с помощью структур данных, которые поддерживают сервисы RTI (RunTime Infrastructure) [16, 19]. RTI - компонент, представляющий собой операционную систему, которая обеспечивает обмен данными между федерациями и федератами.
Далее работа будет сосредоточена на распределенном ИМ.
При распределенном имитационном моделировании первичной единицей является логический процесс - последовательная подмодель, структура которой выглядит как структура последовательной имитационной модели (рис. 1.6).
игра обучение логика тренинговый
Рисунок 1.6. Схема выполнения логического процесса
Каждый ЛП имеет собственный локальный список событий, собственные часы локального модельного времени и собственную управляющую программу (УП). Задача УП - продвижение модели из одного состояния модели в другое, т.е. работа УП состоит в том, чтобы из списка необработанных событий найти событие с минимальной меткой времени и обработать его. Управляющую программу в последовательном ИМ называют симулятором; в распределенном ИМ - алгоритм синхронизации, который предназначен для синхронизации компонентов моделирования (логических процессов) [19].
Логические процессы взаимодействуют исключительно с помощью передачи сообщений. Получив сообщение, которое имеет форму события, логический процесс добавляет это событие (в соответствии со временем) в упорядоченный список своих локальных событий. После чего УП выполняет измененный список событий, т.е. логика выполнения логического процесса-получателя меняется. На рисунке 1.7 изображена схема выполнения распределенной модели, включающая коммуникационную подсистему как отдельный компонент, который синхронизирует модельное время для всех логических процессов. Взаимодействие каждого ЛП с ней осуществляется с помощью некоего коммуникационного интерфейса (КИ) [16, 17].
Хронологический порядок выполнения событий должен отслеживаться алгоритмом управления временем. Если временная метка одного события меньше временной метки другого события, значит, сначала должно быть обработано первое событие, затем второе. Может возникнуть момент, когда второе событие произошло раньше или во время выполнения первого события, а должно было наступить только после окончания первого события. Такая ситуация называется парадоксом времени.
Для исключения возможности появления парадоксов времени в системе распределенного моделирования должна быть реализована специальная программа синхронизации, которая будет входить в состав коммуникационной подсистемы. Такая программа синхронизации (или алгоритм синхронизации) реализует некий алгоритм «синхронизации модельного времени».
Рисунок 1.7. Схема выполнения распределенной модели, КИ - коммуникационный интерфейс, УП - управляющая программа, ПМ - подмодель, ЛП1...N - логические процессы
Если все логические процессы одновременно достигнут некоторого заданного значения модельного времени или в модели не останется будущих событий, моделирование завершается [16].
Существует два класса алгоритмов управления временем: консервативный и оптимистический. Цель этих алгоритмов состоит в том, чтобы сохранить причинно-следственную связь логических процессов, т.е. все процессы должны быть выполнены в неубывающем порядке их временных меток. Консервативный и оптимистический подходы могут быть реализованы с помощью различных механизмов [15-25], которые имеют как преимущества, так и недостатки.
Консервативный подход позволяет избежать всех возможных ошибок причинности. Основная идея консервативных алгоритмов состоит в предотвращении парадоксов времени, т.е. необходимо определить время, когда обработка очередного события из списка необработанных событий будет «безопасной». Событие называют безопасным, если можно гарантировать, что логический процесс в дальнейшем не получит от других логических процессов сообщение с меньшей временной меткой. Консервативный подход не позволяет обрабатывать событие до тех пор, пока не убедится в его безопасности.
Консервативный алгоритм Chandy, Misra и Bryant'а [20, 21] - один из первых консервативных алгоритмов. Реализация алгоритма простая, алгоритм имеет простое управление и структуру данных. Однако механизм синхронизации блокирует процессор и, как следствие, становится подвержен к тупиковым ситуациям. Выходные сообщения, время которых не возрастает монотонно (события со временем задержки), не могут быть легко обработаны. Способ решения данной проблемы - создать сообщение самому себе, указав, что выходное значение будет сгенерировано после задержки [22, 23].
Следующий предложенный Chandy и Misra консервативный алгоритм позволяет избавиться от проблемы с возникновением тупиков, передавая «пустое» или «нулевое» сообщение [24]. Этот алгоритм используется, чтобы объявить об отсутствии реального сообщения, и является дополнительной информацией для определения очередного безопасного события. Тогда некоторый ЛП2, получив такое сообщение от ЛП1, «понимает», что ЛП1 не пришлет сообщение с меньшей временной меткой. Основным недостатком данного алгоритма является большое количество пустых сообщений в случае, если логическому процессу, получившему нулевое сообщение, необходимо отправить вторичные нулевые сообщения с той же меткой времени другим логическим процессам, чтобы сообщить об отсутствии реального сообщения.
В следующих консервативных алгоритмах предполагается усовершенствование последнего алгоритма. К примеру, предлагается отправлять пустое сообщение не всегда, а только по специальному запросу для того, чтобы уменьшить количество нулевых сообщений. Приостановленный логический процесс отправляет запрос всем логическим процессам, сможет ли он выполнить событие с минимальной временной меткой, находящейся за пределами минимальной временной отметки (временного горизонта) [16]. Или же необходимо, чтобы все логические процессы уже владели информацией о значении временной метки следующего необработанного события для того, чтобы вычислить временный горизонт будущих событий процесса.
Также для консервативных алгоритмов синхронизации характерной особенностью является использование предварительного просмотра (lookahead). Величина предварительного просмотра указывает на то, что на протяжении некоторого временного отрезка исходящих сообщений не будет [17].
Что касается оптимистических алгоритмов, то их реализация не предполагает строгого соблюдения ограничений причинно-следственной связи. При выполнении алгоритма оптимистического подхода в распределенном ИМ полагают, что парадоксы времени не возникнут во время параллельного исполнения логических процессов [16]. Если же парадокс времени возник, оптимистические алгоритмы выполняют откат логического процесса до последнего корректного состояния системы для восстановления правильного порядка. Откат включает в себя устранение последствий некорректного исполнения логического процесса и повторное исполнение этого процесса, учитывая сообщение, которое вызвало парадокс времени [16, 25].
Из рассмотренных выше алгоритмов можно сделать следующий вывод: все алгоритмы стараются поддерживать хронологический порядок событий, т.е. суть алгоритма заключается, во-первых, в обеспечении логического порядка наступления событий; во-вторых, в не нарушении временного фактора наступления событий. В СКДИ за логику выполнения отвечает ЛСА, в которой содержатся условия, переходы и осуществляемые операции, необходимо только, чтобы эти операции осуществлялись в соответствии со временем. Для этого были рассмотрены подходы продвижения времени в распределенном ИМ.
Распределенная модель, как было сказано выше, - это модель, состоящая из нескольких последовательных подмоделей, называемых логическими процессами, и одной коммуникационной подсистемы, которая реализует синхронизацию логических процессов. Логический процесс содержит собственные часы локального времени. После анализа алгоритмов распределенного ИМ следующим шагом было решено рассмотреть подходы к продвижению времени, используемые в имитационных системах. Существует три основных алгоритма управления временем:
.Моделирование с фиксированным шагом.
.Моделирование, управляемое событиями.
.Моделирование, управляемое часами реального времени.
При реализации продвижения времени в системе первым способом состояние системы не зависит от наступления события, изменение состояния системы происходит через фиксированные промежутки времени [16, 19]. В каждый такт времени происходит проверка наличия запланированных событий в течение предыдущего интервала времени. Если на интервал были запланированы события, то считается, что эти события происходят в конце этого интервала (рис. 1.8). Проверка также выполняется, если на данный временной интервал событий запланировано не было. Если на проверяемый интервал запланированы два события с разным временем наступления, считается, что оба этих события произошли в конце интервала. Реальное событие можно «привязать» как к концу такта (его правой границе), так и к его началу (левой границе), что зависит от предпочтений или заданных условий [26]. Подход достаточно простой, но присутствует проблема, связанная с определением величины шага [19].
Второй способ предполагает случайный (или особый) шаг продвижения времени, который определяется наступлением событий. В качестве следующего значения часов модельного времени может выбираться событие с минимальной временной меткой. Если же известен закон распределения интервалов между событиями, шаг может определяться с помощью соответствующего датчика. Также при таком подходе могут наличествовать события, для выполнения которых в каждый квант времени необходимо вычислять логические условия, и, если такое условие истинно, событие выполняется.
Моделирование, управляемое часами реального времени, определяется синхронизацией модельного времени с процессорным, однако чаще здесь управление временем в системе зависит от скорости происходящих событий в реальном времени [16, 19].
Рисунок 1.8. Механизмы продвижения модельного времени, E1-7 - события
На рисунке представлены первые два подхода продвижения модельного времени, в некоторых источниках называемые «принцип δt» и «принцип δz», соответственно [26]. При моделировании с фиксированным промежутком времени в данном случае наступление событий приходится на конец такта. На рисунке показано как соотносится время с событиями. Как было сказано выше, δt - фиксированный, а δz - особый промежуток времени.
Изучив алгоритмы, а также подходы к реализации времени в распределенном ИМ, можно спроецировать имитационную модель на подсистему проведения ДИ.
.4 Связь распределенного имитационного моделирования с ППДИ
Выполнение любых действий, требующих реакции, в подсистеме проведения деловых игр производится с помощью модуля «Активный ресурс», который должен реагировать на действия пользователя. Этот модуль выступит в качестве логического процесса, с которым будет взаимодействовать подсистема проведения ДИ. Активных ресурсов, взаимодействующих с ППДИ, может быть несколько, как и логических процессов, используемых при распределенном ИМ. Функции работы самой подсистемы, связанные со временем выполнения операций и событиями, возьмет на себя так называемая управляющая модель (УМ). Работу УМ можно сравнить с управляющей программой в распределенном ИМ, предназначенной для синхронизации логических процессов.
Как основные компоненты моделирования в подсистеме проведения ДИ можно выделить саму подсистему проведения и активные ресурсы, взаимодействие которых с ППДИ будет осуществляться с помощью сообщений. Т.е. вызов активного ресурса будет осуществляться во время выполнения операции, а результатом окончания работы АР будет сообщение подсистеме. Сообщение в рамках ППДИ - это событие, а событие - результат выполнения операции. События в имитационном моделировании - это мгновенное изменение состояния системы.
Предлагается событие сделать видом ресурса, однако события в ППДИ будут двух видов: входной ресурс-событие (РС) и выходной ресурс-событие. Такое разделение необходимо для осуществления управления временем в подсистеме. Входной РС будет знаком для начала выполнения операции, т.е. операция может начать выполняться при наличии входного РС, даже если не наступило время начала операции. Выходной ресурс-событие необходим для перехода к следующей операции. Выходной РС для одной операции является входным РС для другой. Наличие входного или выходного РС для каждой операции задается на этапе проектирования ДИ. Создание выходных РС обеспечивает гарантированный выход из состояния выполнения операции. Также при возникновении активных ресурсов в процессе выполнения операции бизнес-процесса необходимо, чтобы при окончании ЛСА каждого АР происходило формирование события, которое имеет значимость при выполнении операции в основной программе.
События (в нашем случае - операции) должны происходить в хронологическом порядке, т.е. следуя логике и времени. Как было сказано в параграфе 1.2.2, алгоритмы синхронизации модельного времени в распределенном ИМ в нашем случае не подходят, т.к. они учитывают и логику, и время. В СКДИ за логику выполнения отвечает ЛСА, значит, осталось разобраться со временем.
Выполнение операции начинается только тогда, когда есть входной ресурс-событие и текущее время меньше или равно времени наступления выполнения операции. При этом нужно определить, как будет осуществляться продвижение времени при разработке ППДИ. Из рассмотренных в параграфе 1.2.3 алгоритмов продвижения времени продвижение с фиксированным шагом не подойдет, т.к. такое моделирование не будет отражать главного: операция бизнес-процесса должна начать свое выполнение в ППДИ при наступлении времени начала операции, которое у всех операций разное. Моделирование, управляемое часами реального времени, не подойдет, т.к. СКДИ - это студия, содержащая деловые игры, с помощью которых пользователь может получить определенные навыки за короткое моделируемое время.
В таком случае отлично подойдет моделирование с продвижением времени при наступлении события (или на особые моменты времени, или при наличии условий), т.к. в подсистему будут добавлены события, наличие которых позволит перейти к следующей операции. Однако если не было сформировано выходного РС у одной операции, то следующая за ней операция не сможет начаться, т.к. она не будет иметь входного РС.
Физическое время выполнения операций будет задаваться на этапе проектирования ДИ, модельное время выполнения операций будет рассчитываться перед проведением игры, предварительно спросив игрока за какое время он хочет пройти эту игру. Информация о том, какие операции содержат какие входные и выходные ресурсы-события, задается на этапе проектирования деловой игры, как и информация о том, в каких операциях присутствует активный ресурс. Помимо активных ресурсов также на этапе проектирования деловой игры операции присваиваются и другие ресурсы.
Выполнение операции вместе с ее предусловием и постусловием можно представить в виде нескольких шагов:
.Проверка операции и ресурсов на соответствие.
.Проверка операции на наличие входного РС.
.Формирование выходного РС.
.Смена статусов ресурсов.
Выходом из состояния выполнения операции, как было сказано выше, будет точка «Формирование события».
По итогам проецирования элементов распределенного имитационного моделирования на подсистему проведения деловых игр, можно построить следующую таблицу (табл. 1.3):
Таблица 1.3. Проецирование распределенного ИМ на ППДИ
Характеристика / составляющиеППДИРаспределенное ИМКомпонент моделированияППДИ, АРЛПОбъект действияОперация с событиемСобытиеСписок объектовЛокальный (в ППДИ, в АР)Локальный (в ЛП)Часы модельного времениЛокальные (в ППДИ, в АР)Локальные (в ЛП)Программа синхронизации компонентов моделированияУправляющая модель в ППДИКоммуникационная подсистемаВзаимодействие программы синхронизации с компонентами моделированияУП - часть ППДИ. Общение АР с ППДИ с помощью сообщения, ППДИ с АР - программный вызовВзаимодействие ЛП с коммуникационной системой с помощью интерфейса. Между ЛП - обмен сообщениямиЛогическая последовательность объектовСодержится в ЛСАСодержится в коммуникационной подсистеме
Таким образом, определив основные составляющие рассматриваемой подсистемы и обозначив принцип управления временем, следующим шагом необходимо разработать требования к программе, а также новые алгоритмы управления частями ППДИ.
2. Проектирование подсистемы проведения деловых игр с учетом продвижения времени
В данной главе будут представлены требования к программе, определены алгоритмы: алгоритм взаимодействия пользователя с подсистемой проведения ДИ, алгоритм работы самой ППДИ, алгоритм работы модуля «Активный ресурс». Принцип взаимодействия подсистемы проведения ДИ с модулем отражен в диаграмме последовательностей. Разработка таких алгоритмов обусловлена добавлением времени и событий в ППДИ. Также в данной главе описано изменение языка моделей бизне СКДИ.
.1 Разработка требований
Основываясь на требованиях, предъявляемых к данному программному продукту в [12, 13] и добавив возможность настройки и моделирования времени, можно разработать следующие функциональные требования к подсистеме проведения ДИ:
.Пользователь должен иметь возможность задавать модельное время прохождения игры.
.Управляющая модель выполняет перерасчет физического времени операций на модельное.
.Автоматная модель выделяет команду из ЛСА.
.Автоматная модель отправляет команду ОМ.
.Операционная модель получает команду, выводит на экран все доступные для выполнения очередной операции ресурсы из БД согласно команде.
.Пользователь должен иметь возможность выбирать ресурсы.
.ОМ формирует условие, соответствующее действиям пользователя.
.ОМ проверяет выбранные ресурсы на наличие операции в БД.
.ОМ отправляет условие управляющей модели.
.УМ проверяет операции на наличие в БД, на время, на наличие активных ресурсов и ресурсов-событий.
.УМ формирует выходной ресурс-событие.
.УМ отправляет условие АМ.
.АМ принимает условие, выполняет поиск ЛСА в БД, выделяет из нее команду.
.АМ отправляет команду ОМ.
.УП проверяет конец времени операции.
.Пользователь должен иметь возможность получения результата выполнения операции или ошибки после нажатия на кнопку «Выполнить операцию».
.АМ по условию переходит к п. 3.
.2 Разработка алгоритма взаимодействия пользователя с ППДИ
Перед тем, как определить функциональные требования, предъявляемые к программе, можно разработать алгоритм взаимодействия игрока с системой с учетом времени:
.Пользователь задает модельное время прохождения игры.
.Система производит перерасчет физического времени операций на модельное.
.Система выводит на экран все доступные для выполнения очередной операции ресурсы согласно ЛСА.
.Пользователь выбирает ресурсы.
.Пользователь нажимает на кнопку «Выполнить операцию».
.Пользователь ждет результата от системы.
.Система сообщает о результате выполнения операции или об ошибке.
.Пока не конец игры, повторять п. 3-7.
.3 Разработка алгоритма работы ППДИ
При разработке алгоритма работы ППДИ с проверкой времени и формированием событий необходимо учесть следующие моменты:
·Работу, связанную с событиями и временем, выполняет управляющий модуль.
·Начать выполнение операции можно только если у операции есть входной ресурс-событие и текущее время меньше или равно времени наступления этой операции, иначе конец игры.
·Наличие входного РС означает, что он был сформирован в предыдущей операции (кроме первой операции - в начале игры входным РС является событие «Игра началась»).
·Длительность операции - максимально возможный промежуток времени, который она может продолжаться. Операция может завершиться до того, как время выполнения операции закончилось, если был сформирован выходной ресурс-событие.
·Выходной РС формируется при окончании выполнения операции, если не был сформирован ранее.
·Ресурс может быть не доступен для выбора пользователем, может быть доступен и может быть выбран. Статус доступных ресурсов помечается как «0» (ноль), выбранных- как «1» (единица), всех остальных - «-» (прочерк) или «» (пустота, null).
Алгоритм работы ППДИ, разделенный на работу отдельных модулей, выглядит следующим образом:
1.АМ выполняет запрос к БД, загружает ЛСА.
2.АМ выделяет команду с первой моделью сцены.
.АМ отправляет команду ОМ.
.ОМ получает команду, выводит на экран все доступные для выполнения очередной операции ресурсы согласно ЛСА.
.ОМ формирует условие, отвечающее действиям пользователя, для перехода к следующей сцене. Лист ресурсов обновляется после выбора ресурсов игроком: ресурсы, которые выбрал пользователь, меняют статус с «0» на «1».
.ОМ выполняет запрос к БД, проверяет выбранные ресурсы на наличие операции, имеющей на входе такой набор входных ресурсов: если такая операция в есть, то переход к п. 7; если такой операции найдено не было, то на экран игроку выводится сообщение с информацией об ошибке, переход к п. 8.
.Выполнение операции:
7.1.УМ проверяет наличие входного ресурса-события в операции и проверяет время: если есть входной ресурс-событие и текущее время меньше или равно времени начала операции, то переход к п. 7.2, иначе вывод сообщения об ошибке, переход к п. 8.
7.2.УМ формирует выходной ресурс-событие.
.3.ОМ отправляет условие, содержащее статусы ресурсов, АМ.
.4.АМ принимает условие, выполняет запрос к БД.
.5.АМ находит ЛСА, выделяет команду (со следующей моделью сцены) из ЛСА.
.6.АМ отправляет команду ОМ. Смена статусов ресурсов: входные ресурсы становятся недоступными (статус «-»); выходные ресурсы становятся доступными (статус «0»).
.7.УМ проверяет время, выделенное на выполнение операции: если время не закончилось, то переход к п. 8, иначе на экран игроку выводится сообщение с информацией об ошибке, переход к проверке конца игры.
8.Пока не конец игры, повторять п. 4-7.
Алгоритм работы ППДИ наглядно представлен ниже в виде блок-схемы на рисунках 2.1, детализация блока «Выполнение операции» - на рисунке 2.2.
Рисунок 2.1. Алгоритм работы ППДИ
Рисунок 2.2. Алгоритм работы ППДИ: детализация блока «Выполнение операции»
2.3 Разработка алгоритма работы АР
При разработке такого алгоритма необходимо учесть следующие моменты:
·Если есть активные ресурсы, то ЛСА каждого АР выполняется одновременно с ЛСА ППДИ. Как только нашелся в БД очередной АР у операции, сразу включается в работу ЛСА этого АР. Получается, что ЛСА каждого АР операции включается в работу последовательно. Тогда ЛСА всех активных ресурсов и ППДИ будут выполняться в разных потоках одновременно.
·Если есть АР и сообщения пришли от всех АР, тогда можно сформировать событие раньше, чем закончится выполнение операции.
·Если сообщения пришли не от всех АР, то нужно ждать сообщения от всех, пока не закончится время на выполнение операции.
Выполнение АР происходит на этапе выполнения операции при наличии АР у операции. Тогда блок-схему (рис. 2.2) можно дополнить так, как изображено на рисунке 2.3 (начало) и 2.4 (продолжение). Алгоритм будет следующим:
.ОМ выполняет запрос к БД, проверяет на использование в операции активного ресурса: если в операции задействован активный ресурс (активные ресурсы), то АМ загружает ЛСА АР, иначе переход к проверке конца игры.
.УМ проверяет наличие сообщений от всех АР: если есть в наличии сообщения от всех активных ресурсов, задействованных в операции, переход к формированию события, если в наличии сообщения не от всех активных ресурсов, то переход к следующему пункту (п. 3).
.УМ проверяет время, выделенное на выполнение операции: если время не закончилось, то УМ ждет сообщения, переход к п. 2, иначе на экран игроку выводится сообщение с информацией об ошибке, переход к проверке конца игры.
Рисунок 2.3. Алгоритм работы модуля «АР» (начало)
Рисунок 2.4. Алгоритм работы модуля «АР» (продолжение)
Взаимодействие между ППДИ и АР будет представлено ниже в виде диаграмм последовательностей.
.4 Проектирование с использованием диаграмм
После определения алгоритма работы пользователя с подсистемой проведения ДИ, принципа работы подсистемы и модуля «Активный ресурс» необходимо указать принцип взаимодействия между пользователем, моделями подсистемы и модулем «АР» с использованием событий и с учетом времени. Для этого была нарисована диаграмма прецедентов. Для проектирования подсистемы проведения ДИ следует разработать диаграмму прецедентов в соответствии с выше представленными требованиями (см. рис. 2.5):
В диаграмме прецедентов можно выделить двух акторов: пользователь и БД. Пользователь настраивает модельное время при запуске игры и выбирает ресурсы во время ее проведения. При запуске игры начинается выполнение сценария игры. База данных предназначена для загрузки ресурсов и моделей сцены.
Диаграмма прецедентов содержит следующие прецеденты:
1.Запуск игры.
2.Настройка времени.
3.Игра.
4.Выбор ресурсов.
5.Получение результатов выполнения операции.
6.Выполнение операции.
7.Загрузка модели сцены.
8.Запуск АР.
Рисунок 2.5. Диаграмма прецедентов
Ниже представлены таблицы 2.1-2.6 с описаниями прецедентов. Таблица 2.1 с описанием прецедента «Запуск игры» содержит описание подпотока «Настройка времени».
Таблица 2.1. Описание прецедента «Запуск игры»
Краткое описаниеПрецедент запускает игруАкторыПользовательПредусловияПрограмма запущенаОсновной потокОткрывается начальное окно приложения Подпоток «Настройка времени»: Открывается окно для настройки модельного времени Пользователь задает модельное время прохождения игрыАльтернативные потокиВывод ошибки в случае задания модельного времени из недопустимого диапазонаПостусловияЕсли прецедент был успешным, выполняется загрузка ЛСА
Прецедент «Игра» содержит подпоток «Выбор ресурсов», описание которых представлены в таблицах 2.2 и 2.3. прецедент «Выбор ресурсов» содержит две точки расширения» «Выполнение операции» и «Запуск АР».
Таблица 2.2. Описание прецедента «Игра»
Краткое описаниеПрецедент запускает игруАкторыПользовательПредусловияМодельное время игры настроеноОсновной потокАМ выполняет запрос к БД, загружает ЛСА АМ выделяет команду с первой моделью сцены АМ отправляет команду ОМ ОМ получает команду, выводит на экран все доступные для выполнения очередной операции ресурсы согласно ЛСААльтернативные потокиВывод ошибки в случае не задания модельного времениПостусловияЕсли прецедент был успешным, игра успешно запустилась
Таблица 2.3. Описание прецедента «Выбор ресурсов»
Краткое описаниеПрецедент позволяет пользователю выбрать ресурсыАкторыПользователь, база данныхПредусловияМодель сцены сгенерирована, ресурсы отображены на экранеОсновной потокПользователь выбирает необходимые ему ресурсы для выполнения какой-либо операции ОМ формирует условие для перехода к следующей сцене ОМ выполняет запрос к БД, проверяет выбранные ресурсы на наличие операции, имеющей на входе такой набор входных ресурсов Альтернативные потокиЕсли пользователь выбрал неверные ресурсы, предназначенные для выбранного действия, выводится ошибка, пользователю необходимо заново выбрать ресурсы Если пользователь не выбрал ресурсы, выводится ошибка, пользователю необходимо заново выбрать ресурсыПостусловияЕсли прецедент был успешным, ресурсы отмечены как выбранныеТочка расширенияВыполнение операции Запуск АР
Таблица 2.4 с описанием прецедента «Выполнение операции» содержит описание подпотока «Получение результатов выполнения операции». Описание подпотоков «Запуск АР» и «Загрузка модели сцены» содержатся в таблицах 2.5 и 2.6 соответственно.
Таблица 2.4. Описание прецедента «Выполнение операции»
Краткое описаниеПрецедент позволяет сымитировать выполнение операции с использованием заранее выбранных ресурсовАкторыБаза данных, ПользовательПредусловияПользователь выбрал ресурсы необходимые для выполнения этой операцииОсновной потокУМ проверяет наличие входного ресурса-события в операции и проверяет время ОМ выполняет запрос к БД, проверяет на использование в операции активного ресурса: если в операции задействован активный ресурс (активные ресурсы), то АМ загружает ЛСА АР УМ формирует выходной ресурс-событие ОМ отправляет условие, содержащее статусы ресурсов, АМ АМ принимает условие, выполняет запрос к БД АМ находит ЛСА, выделяет команду из ЛСА АМ отправляет команду ОМ УМ проверяет время, выделенное на выполнение операции Подпоток «Получение результатов выполнения операции»: 1. Вывод сообщения о результате выполнения операцииАльтернативные потокиЕсли входного РС нет, выводится ошибка Если есть АР, то включается в работу ЛСА этого АР Если время начала операции больше текущего, выводится ошибка Если время операции закончилось, выводится ошибка о превышении времени выполнения действия, игра завершается Если АМ возвращает команду на завершение игры, игра завершаетсяПостусловияЕсли прецедент был успешным, ОМ получает новую модель сцены
Таблица 2.5. Описание прецедента «Запуск АР»
Краткое описаниеПрецедент позволяет сымитировать выполнение операции с использованием заранее выбранных ресурсовАкторыБаза данных, ПользовательПредусловияВ операции задействован активный ресурсОсновной поток1. ОМ выполняет запрос к БД, проверяет на использование в операции активного ресурса: если в операции задействован активный ресурс (активные ресурсы), то АМ загружает ЛСА АР 2. УМ проверяет наличие сообщений от всех АР: если есть в наличии сообщения от всех активных ресурсов, задействованных в операции, переход к формированию события, если в наличии сообщения не от всех активных ресурсов, то переход к пункту 2.2. 3. УМ проверяет время, выделенное на выполнение операции: если время не закончилось, то УМ ждет сообщения, переход к п. 2.1Альтернативные потокиЕсли ЛСА АР нет в БД, выводится ошибкаПостусловияЕсли прецедент был успешным, ЛСА АР запущена
Таблица 2.6. Описание прецедента «Загрузка модели сцены»
Краткое описаниеПрецедент осуществляет выгрузку модели сцены из БДАкторыБаза данныхПредусловияРесурсы правильно выбраны пользователемОсновной потокОМ по коду операции делает запрос к БД на получение модели сценыАльтернативные потокиПри возникновении проблем с получением данных выводится соответствующая ошибкаПостусловияЕсли прецедент был успешным, ресурсы отображены на экране
Описание бизнес-процесса позволяет понять контекст возникновения прецедентов. Для описания БП удобно использовать диаграммы активностей языка UML (Приложение 1). Для отображения состава, порядка и параметров системных сообщений используется диаграмма последовательностей
Диаграммы последовательностей для прецедентов «Выполнение операции» и «Запуск АР» хорошо демонстрируют принцип взаимодействия между пользователем, подсистемой и модулем «АР» с использованием событий и с учетом времени (см. рис 2.6, 2.7).
Проектирование системы с помощью диаграмм позволяет лучше представить разрабатываемые функции системы и понять логику их построения. Далее следует обратиться к СКДИ и построить модели бизнес-процессов на конкретном примере, который будет отражать новые характеристики системы: время и события.
Рисунок 2.6. Диаграмма последовательностей прецедента «Выполнение операции»
Рисунок 2.7. Диаграмма последовательностей для прецедента «Запуск АР»
2.4 Проектирование моделей бизнес-процессов для построения сценария, выполняющегося подсистемой проведения ДИ
В связи с необходимостью добавления времени в алгоритмы СКДИ должен измениться язык моделей бизнес-процессов СКДИ. Изменения были внесены в язык модели унифицированного бизнес-процесса.
Кроме названия операции в модели операции указано время начала операции, время ее выполнения (длительность) и событие, формирующееся в процессе выполнения операции или после ее завершения. Время начала и время выполнения операции будут задаваться на этапе проектирования деловой игры с указанием единиц времени, событие также будет определяться на этапе проектирования, где необходимо будет указать, какие ресурсы являются событиями. На рисунке 2.8 представлена модель «Операция» для операции 1 основной программы.
Рисунок 2.8. Модель операции для операции 1
Модели операций для АР также содержат дополнительные параметры как модели операций для основной программы (время начала, время выполнения, событие), однако заполнение этих моделей будет происходить в учебном унифицированном БП, т.к. активных ресурсов одного типа может быть несколько и каждый будет иметь определенную модель поведения.
Для реализации и последующей исправной работы подсистемы проведения ДИ требуется спроектировать базу данных. В СКДИ работа с базой данных относится к операционной модели, которая построена на взаимодействии ресурсов и их отображении на экране (модели сцены, экрана и ресурсов).
В работах [1, 6] БД уже была спроектирована, однако требуется ее модификация, т.к. в рамках текущей работы, во-первых, внимание акцентируется больше на внутреннюю реализацию подсистемы, а не на визуализацию, во-вторых, произошло добавление событий и времени операций. Инфологическая модель БД подсистемы представлена на рисунке 2.9.
Также на рисунке показаны связи между таблицами. Например, создание таблицы «Операция в бизнес-процессе» и связи один-ко-многим (1:N) между таблицами «Бизнес-процессы» и «Операция в бизнес-процессе» обусловлено тем, что между операциями и бизнес-процессами существует связь многие-ко-многим (один бизнес-процесс может содержать в себе несколько операций и одна операция может быть в нескольких бизнес-процессах), что требует нормализации при проектировании БД. Аналогично была создана таблица «Ресурс в операции».
Рисунок 2.9. Инфологическая модель БД ППДИ
Таблица «Типы ресурсов» является справочником. Связь между таблицами «Типы ресурсов» и «Ресурсы» 1:N, т.к. один ресурс может объединять в себе несколько типов (в зависимости от операции ресурс может быть как входным, так и выходным).
На рисунке 2.10 - база данных, созданная в SQL Server, с полями каждой таблицы. Таблицы «Бизнес-процессы», «Операции» и справочник «Типы ресурсов» содержат в себе такие поля как код, название и описание. Таблица «Ресурсы» кроме кода, названия и описания содержит поле «Код типа ресурса» и поле «ЛСА», которое заполняется для активных ресурсов.
Рисунок 2.10. БД ППДИ в MS SQL Server
Таблица «Операция в бизнес-процессе» содержит ключевое поле «Код», коды бизнес-процессов и операций. Т.к. одна и та же операция может в разных БП иметь разное время начала и длительность, то поля «Время начала» и «Время выполнения» операции находятся в данной таблице.
Таблица «Ресурс в операции» содержит ключевое поле «Код», коды операций и ресурсов, а также логическое поле, которое сообщает, является ли данный ресурс в конкретной операции событием или нет.
Все идентификаторы (id) имеют тип данных bigint, логические поля -логический тип (bit), поле «Время начала операции» (start_time) - тип date, остальные поля - строковый тип (nvarchar).
Ниже представлено описание полей в каждой таблице (табл. 2.7-2.12).
Таблица 2.7. Таблица business_process
ПолеТип данныхОписаниеid_business_processbigintКлючевое поле, идентификатор БПname_business_processnvarcharИмя БПdescription_business_processnvarcharОписание БП
Таблица 2.8. Таблица operation_in_business_process
ПолеТип данныхОписаниеidbigintКлючевое полеid_business_processbigintИдентификатор БПid_operationbigintИдентификатор операцииstart_timedateВремя начала операцииprocess_timebigintДлительность операции
Таблица 2.9. Таблица operations
ПолеТип данныхОписаниеid _operationbigintКлючевое поле, идентификатор операцииname_operationnvarcharИмя операцииdescription_operationnvarcharОписание операции
Таблица 2.10. Таблица resource_in_operations
ПолеТип данныхОписаниеidbigintКлючевое полеid_operationbigintИдентификатор операцииid_resourcebigintИдентификатор ресурсаis_it_eventbitЯвляется ли ресурс событием
Таблица 2.11. Таблица resources
ПолеТип данныхОписаниеid_resourcebigintКлючевое поле, идентификатор ресурсаname_business_processnvarcharИмя ресурсаdescription_business_processnvarcharОписание ресурсаid_resource_typebigintИддентификатор типа ресурсаLSAnvarcharСтрока ЛСА
Таблица 2.12. Таблица resource_types
ПолеТип данныхОписаниеid_typebigintКлючевое поле, идентификатор типа ресурсаname_resource_typenvarcharНазвание типа ресурсаdescription_resource_typenvarcharОписание типа ресурса
3.Разработка прототипа подсистемы
После проведения анализа предметной области, разработки алгоритмов работы в ППДИ и проектирования базы данных необходимо перейти к разработке подсистемы. Для начала был разработан контрольный пример, на котором будет проверяться разработанный прототип подсистемы. Дальше были спроектированы экранные формы подсистемы проведения деловых игр и разработан прототип подсистемы.
.1 Разработка контрольного примера
Разработка примера проводилась с учетом изменения языка УБП, описанного во 2 главе. Пример представлен в виде трех моделей бизнес-процесса «Формирование приказа на курсовую работу»: рабочего, унифицированного и учебного унифицированного.
Упрощенную модель РБП «Формирование приказа на курсовую работу» можно продемонстрировать на примере с помощью нотации IDEF0 (рис. 3.1, 3.2). Такая методика подходит для начальных стадий проектирования систем, включающих людей, оборудование, программное обеспечение.
Рисунок 3.1. Диаграмма IDEF0 для РБП «Формирование приказа на курсовую работу» (начало)
Рисунок 3.2. Диаграмма IDEF0 для РБП «Формирование приказа на курсовую работу» (продолжение)
Здесь А1-А5 - это осуществляемые в бизнес-процессе академическим руководителем действия, которые звучат следующим образом:
.Собрать темы от научных руководителей.
.Сформировать список тем для студентов.
.Отправить темы студентам.
.Сформировать список тем для приказа.
.Сформировать приказ.
В таблице 3.1 представлено описание диаграммы IDEF0 для каждой операции с указанием входных и выходных ресурсов, управляющих ресурсов, ресурсов-механизмов и исполнителей, которые на диаграмме показаны стрелками к блоку (соответственно, слева, справа, сверху, снизу).
Таблица 3.1. Описание диаграммы IDEF0 для РБП «Формирование приказа на курсовую работу»
№ОперацияВходные ресурсыВыходные ресурсыМеханизмыИсполнителиА1Собрать темы от научных руководителейТемы от научных руководителейСписок тем от научных руководителейСредства коммуникации, текстовый редакторАкадемический руководительА2Сформировать список тем для студентовСписок тем от научных руководителейСписок тем для студентовТекстовый редакторАкадемический руководительА3Отправить темы студентамСписок тем для студентовСписок тем от студентовСредства коммуникацииАкадемический руководитель, студентА4Сформировать список тем для приказаСписок тем от студентовСписок тем для приказаТекстовый редакторАкадемический руководительА5Сформировать приказСписок тем для приказа, шаблон приказаПриказАСАВАкадемический руководитель
Исполнителем может быть не только игрок, т.к. существуют такие действия, которые происходят в результате совершения каких-либо других действий. В связи с тем, что выполнение любого действия влечет за собой включение в работу ресурсов, то в такой ситуации роль исполнителя берет на себя активный ресурс. В данном примере академический руководитель отправляет письмо со списком тем курсовых работ студентам, далее студенты должны выбрать тему из этого списка (или же предложить свою тему) и известить академического руководителя о своем выборе. В роли студентов выступят активные ресурсы.
Работа активного ресурса «Выбор темы курсовой работы» представлена ниже в нотации IDEF0 (рис. 3.3), описание диаграммы IDEF0 приведено в таблице 3.2.
Рисунок 3.3. Диаграмма IDEF0 для АР «Выбор темы курсовой работы»
Действия студента (модуль «Активный ресурс»):
.Выбрать тему из предложенных / предложить свою тему.
.Отправить тему академическому руководителю.
Таблица 3.2. Описание диаграммы IDEF0 АР «Выбор темы курсовой работы»
№ОперацияВходные ресурсыВыходные ресурсыМеханизмыУправляющая информацияА1Выбрать тему из предложенныхСписок тем для студентовВыбранная темаПредпочтения студентаА2Предложить свою темуСписок тем для студентовПридуманная темаТекстовый редакторИдея студентаА3Отправить тему академическому руководителюВыбранная/ придуманная темаТемаСредства коммуникации
Данный пример также можно описать с помощью нотации DFD. Ниже продемонстрирована модель рабочего бизнес-процесса (рис. 3.4) и модель активного ресурса (см. рис. 3.5). Нотация DFD (диаграммы потоков данных) является дополнением к IDEF0. [27].
Рисунок 3.4. Диаграмма DFD для РБП «Формирование приказа на курсовую работу»
Рисунок 3.5. Диаграмма DFD для АР «Выбор темы курсовой работы»
Для того чтобы в процессе прохождения игры учитывалось время, были внесены изменения в модель унифицированного БП. На рисунке 3.6 представлена последовательность операций основной программы, на рисунках 3.7 - 3.11 - модели операций для каждой операции основной программы.
Рисунок 3.6. Последовательность операций БП «Формирование приказа на курсовую работу»
Рисунок 3.7. Модель операции для операции А1
Рисунок 3.8. Модель операции для операции А2
Рисунок 3.9. Модель операции для операции А3
Рисунок 3.10. Модель операции для операции А4
Рисунок 3.11. Модель операции для операции А5
Операции каждого АР «Выбор темы курсовой работы» имеют собственные параметры: время начала, длительность и событие, как модели операций для основной программы. Как уже говорилось в главе 2, заполнение моделей операций для АР будет происходить в УУБП, т.к. активных ресурсов одного типа может быть несколько и у каждого будет собственная модель поведения. Ниже представлены последовательность операций активного ресурса «Выбор темы курсовой работы» (рис. 3.12) и модели операций для каждой операции активного ресурса (рис. 3.13-3.15).
Рисунок 3.12. Последовательность операций АР «Выбор темы курсовой работы»
Рисунок 3.13. Модель операции для операции А1 активного ресурса
Рисунок 3.14. Модель операции для операции А2 активного ресурса
Рисунок 3.15. Модель операции для операции А3 активного ресурса
Эталонной моделью учебного унифицированного бизнес-процесса считается карта операций с единственной, «идеальной», траекторией прохождения деловой игры. Именно такая траектория будет использоваться в процессе обучения для формирования игроком «правильных» компетенций. Ниже представлена карта операций «Формирование приказа на курсовую работу» (рис. 3.16 и 3.17).
Рисунок 3.16. Карта операций «Формирование приказа на курсовую работу» (начало)
Рисунок 3.17. Карта операций «Формирование приказа на курсовую работу» (продолжение)
Также можно построить карту операций для активного ресурса «Выбор темы курсовой работы» в общем виде (рис. 3.18) и для каждого АР в отдельности с указанием дополнительных параметров как в модели основной программы (см. рис. 3.19, 3.20).
Рисунок 3.18. Карта операций для АР «Выбор темы курсовой работы» в общем виде
Для того чтобы соблюдалась логическая последовательность действий, в СКДИ принято использовать логическую схему алгоритма. Кроме того, что ЛСА несет в себе логику выполнения операций, она позволяет записать алгоритм в строчку, что удобно при дальнейшей реализации программы. Для обозначения взаимосвязей между операторами (операциями) и логическими условиями используются верхние и нижние стрелки [28].
Для бизнес-процесса «Формирование приказа на курсовую работу» ЛСА выглядит следующим образом:
Н p1↑1 ω↑6 ↓1 A1 p2↑2 ω↑6 ↓2 A2 p3