Компетентностная деловая игра
Компьютерные деловые игры как наиболее эффективные методы активного обучения. Имитация реальной обстановки для лучшего восприятия информации, оптимального построения логики решений и получения удовлетворительных результатов учебно-тренинговой системы.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 11.08.2017 |
| Размер файла | 1,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Введение
В последние годы популярным методом получения знаний являются деловые игры (ДИ). В частности, компьютерные деловые игры являются одним из наиболее эффективных методов активного обучения и широко применяются как в учебном процессе в системе высшего и среднего образования, так и в корпоративном обучении [1]. Деловые игры имитируют реальную обстановку, обеспечивают условия, максимально приближенные к реальным, для лучшего восприятия информации, оптимального построения логики и решений и получения удовлетворительных результатов в итоге [2]. Такой способ освоения материала является довольно интересным, так как позволяет соотносить все процессы игры с реальным миром и, сопоставляя их с реальными ситуациями, принимать решения.
Компьютерная деловая игра представляет собой учебно-тренинговую компьютерную систему, которая используется как при подготовке бакалавров, магистров и специалистов различных профилей, так и для обучения и повышения квалификации персонала. Обычно деловые игры применяют в сфере экономики и менеджмента, к примеру, компьютерные деловые игры серии «Бизнес-Курс» [3, 4], «Никсдорф Дельта» компании «ГРЕЙТ» [5, 6], игра «Factory» компании Team Training [7], деловые игры BI TO BI [8] и др. Эти игры направлены на развитие совокупности профессиональных навыков и качеств руководителей и сотрудников компаний.
В рамках данной работы была выполнена работа по проектированию и разработке прототипа подсистемы проведения деловой игры (ППДИ) студии компетентностных деловых игр (СКДИ). СКДИ является инструментальной средой для проектирования и проведения деловых игр [1, 2, 9, 10, 11]. В рамках СКДИ была разработана модель проведения деловой игры [9], которую необходимо реализовать в виде программного продукта. Была спроектирована архитектура ППДИ и разработан ее прототип. Также был спроектирован и разработан прототип модуля ППДИ - «Активный ресурс» (АР) [12, 13], который выступает в роли исполнителя и выполняет действия, заложенные в его сценарий.
Работа подсистемы проведения деловых игр заключается в следующем: при проведении деловой игры (ДИ) игрок выбирает различные ресурсы, затем выполняется определенная операция бизнес-процесса (БП). После выполнения очередной операции система должна предложить игроку доступные ресурсы. В процессе игры необходимо следить за тем, чтобы очередная операция БП выполнялась строго в хронологическом порядке. Если же текущий БП сначала должен получить ответ от модуля «Активный ресурс», то система сначала должна дождаться этого ответа и только потом в зависимости от него предложить доступные для выполнения очередной операции БП ресурсы. Очередная операция может оказаться доступной для выполнения, когда все ресурсы, необходимые для ее осуществления, доступны пользователю для выбора, и операция должна выполниться до наступления окончания времени, выделенного на операцию.
Прототип, разработанный на данный момент, позволяет игроку выбрать ресурсы для выполнения очередной операции БП, после чего система выполняет соответствующие действия согласно логической схеме алгоритма (ЛСА), но при этом не учитывает хронологический порядок бизнес-процессов. Модели бизнес-процессов, используемые при проектировании ДИ, также не учитывают фактор времени. Исследуемой в данной работе проблемой является отсутствие при проведении деловой игры настройки времени выполнения операций бизнес-процесса и возможности моделирования выполнения операций во времени. Разрабатываемый в рамках данной работы продукт позволит решить этот вопрос посредством внедрения механизма синхронизации времени, который будет контролировать процесс своевременного выполнения всех операций, следовательно, тема работы является актуальной.
Помимо структуры подсистемы проведения ДИ и алгоритмов ее исполнения в текущей работе описан принцип распределенного имитационного моделирования (ИМ), основные подходы к управлению временем в таком моделировании. Также в работе проанализированы некоторые алгоритмы реализации распределенной имитационной модели, выполнено проектирование ППДИ с использованием распределенного ИМ и описана реализация прототипа подсистемы с учетом выполненного проектирования.
Теперь можно выделить объект и предмет исследования. Объектом исследования является взаимодействие пользователя с подсистемой проведения деловых игр, предметом исследования - реализация взаимодействия пользователя с подсистемой с использованием метода распределенного ИМ.
Целью выпускной квалификационной работы является проектирование и разработка подсистемы проведения деловых игр, используя метод распределенного имитационного моделирования.
Для достижения поставленной цели необходимо решить следующие задачи:
1. Анализ существующих на данный момент алгоритмов для проектирования и проведения ДИ в студии компетентностных деловых игр.
2. Анализ алгоритмов и подходов к управлению временем, реализующих распределенное имитационное моделирование.
3. Формулировка требований к подсистеме проведения ДИ.
4. Разработка алгоритмов работы ППДИ.
5. Проектирование ППДИ с использованием диаграмм.
6. Проектирование моделей бизнес-процессов для построения сценария, выполняющегося ППДИ и разработка контрольного примера.
7. Проектирование ЛСА, реализующей сценарий ДИ, с учетом исполнения соответствующего БП во времени.
8. Проектирование базы данных (БД) подсистемы проведения ДИ.
9. Проектирование форм.
10. Разработка прототипа ППДИ.
11. Тестирование ППДИ с использованием разработанного контрольного примера.
Для выполнения данных задач были использованы следующие методы: метод функционального моделирования, объектно-ориентированное проектирование, объектно-ориентированное программирование, имитационное моделирование.
Практическая значимость работы заключается в модификации процесса проведения деловой игры. Разрабатываемая система будет учитывать порядок выполнения операций бизнес-процессов во времени, что позволит приблизить моделируемые процессы в ППДИ к реальным и поможет при дальнейшей доработке студии компетентностных деловых игр.
Результатом работы является прототип ППДИ, который позволяет провести деловую игру с учетом времени выполнения операций.
1. Анализ предметной области
В самом начале работы требуется проанализировать область, представляющую интерес в текущей работе. В данной главе описана общая структура студии компетентностных деловых игр, в частности подсистемы проведения, а также выполнен обзор алгоритмов распределенного имитационного моделирования.
1.1 Описание структуры СКДИ
Компетентностная деловая игра - это информационная система, целью которой является получение определенного уровня профессиональных компетенций в процессе реализации сценариев, определяемых моделями бизнес-процессов предметной области. Студия компетентностных деловых игр выступает инструментарием для разработки и проведения таких деловых игр. Сотрудниками кафедры информационных технологий в бизнесе, в рамках которой разрабатывается СКДИ, был предложен многомодельный подход к разработке такой инструментальной среды [2]. Структурная схема СКДИ представлена на рисунке 1.1.
Рисунок 1.1. Структурная схема СКДИ
В рамках данной работы будут рассмотрены подсистемы проектирования и проведения. Подсистема проектирования ориентирована на разработку сценариев деловых игр, моделей предметных областей, на базе которых выполняются сценарии, также с помощью подсистемы проектирования могут создаваться учебно-методические материалы для проведения игр и контрольно-измерительные материалы. Исходные данные для подсистемы проектирования представляет модель предприятия в неформализованном виде [2].
После проектирования деловой игры формализованная модель данных должна быть наполнена самими данными, что производится в рамках подсистемы проведения [14]. В подсистеме проведения происходит выполнение сценария деловой игры и создается деловая обстановка, в которой игрок принимает решения, тем самым формируя определенный набор компетенций. Деловая обстановка представляет собой совокупность различных ресурсов, доступных для игрока. При проведении деловой игры игрок выбирает различные ресурсы, после чего происходит выполнение определенной операции бизнес-процесса. Дальше система предлагает игроку доступные для выполнения очередной операции БП ресурсы.
Некоторые существующие в игре ресурсы могут играть активную роль (оппонент или активный ресурс), работа которых осуществляется в отдельном модуле. Модуль «Активный ресурс» выступает в роли исполнителя, т.е. исполнителем может быть не только игрок, поскольку существуют такие действия, которые происходят в результате совершения каких-либо других действий. АР выполняет операцию как отдельный участник на основе существующих данных либо запрашивая дополнительную информацию у игрока [12].
Как подсистема проведения ДИ, так и модуль «Активный ресурс» предполагает наличие автоматной и операционной моделей (АМ, ОМ). В АМ происходит выполнение алгоритма, заложенного в сценарий ДИ. В качестве такой модели используется полученная на этапе проектирования логическая схема алгоритма. В ОМ формируется деловая обстановка на основе команды, поступающей из АМ. ОМ представляет собой множество наборов, включающих модель экрана, модель сцены и модель ресурсов (или Ресурсы) [13].
Алгоритм выполнения операции, включающий определенные в [12] функции АМ и ОМ, следующий:
1. Пользователь выбирает ресурсы.
2. Операция выполняется:
2.1. ОМ формирует условие, отвечающего действиям пользователя, для перехода к следующей сцене.
2.2. ОМ отправляет условие АМ.
2.3. АМ принимает условие, выполняет запрос к БД.
2.4. АМ выделяет команду из ЛСА.
2.5. АМ отправляет команду ОМ.
3. ОМ получает команду, выполняет запрос к БД, ищет модель сцены.
4. ОМ выбирает из БД ресурсы, соответствующие текущей модели сцены.
5. ОМ загружает ресурсы в модель экрана (выводит на экран).
Также в работе [12] были определены функции, выполняемые активным ресурсом:
1. Загрузка ЛСА из БД.
2. Выделение команды из ЛСА (выполняется автоматной моделью).
3. Выбор модели сцены и ресурсов (диалоговых окон) по команде (выполняется ОМ).
4. Вывод на экран с помощью МЭ ресурсов из БД, соответствующих модели сцены (выполняется ОМ).
5. Получение ответов игрока (выполняется ОМ).
Однако в системе нельзя задать время выполнения операций и смоделировать выполнение операций во времени, т.е. все операции выполняются в логическом порядке (согласно ЛСА), но без учета времени. В рамках данной работы предполагается применить распределенную имитационную модель к существующим алгоритмам в СКДИ, что поможет приблизить деловую обстановку в игре к реальной.
1.2 Анализ моделей бизнес-процессов СКДИ
Чтобы применить распределенную имитационную модель в СКДИ, необходимо проанализировать разработанные в рамках СКДИ алгоритмы, а именно языки моделей бизнес-процессов, которые не отображают временные характеристики БП на данный момент. В СКДИ используются понятия трех моделей бизнес-процессов: реального (существующего на предприятии), унифицированного (промежуточного между реальным и учебным) и учебного унифицированного (на котором можно обучать). В рабочем (или реальном) бизнес-процессе (РБП) имеются определенные действия, их исполнители и различные ресурсы, необходимые для осуществления действий и получаемые в результате реализации действий. Пример диаграммы IDEF0 для абстрактного РБП (см. рис. 1.2):
Рисунок 1.2. Пример диаграммы IDEF0 для РБП
Здесь D1...D4 - это действия (или операции), осуществляемые в бизнес-процессе, R1…R6 - ресурсы на входе и выходе действий, U1, U2, U3 - управление действиями, I1, I2 - исполнители действий, M1, M2 - механизмы (табл. 1.1).
Таблица 1.1. Описание диаграммы IDEF0
|
Вход |
Действие |
Выход |
Исполнитель |
|
|
R1, R2 |
D1 |
R3 |
I1 |
|
|
R3 |
D2 |
R4 |
I1 |
|
|
R4 |
D3 |
R5 |
I2 |
|
|
R5 |
D4 |
R6 |
I1 |
Выполняемые на предприятиях реальные бизнес-процессы не могут использоваться как модели при проектировании деловых игр, поскольку они сложны, могут содержать ошибки при неправильной организации работы предприятия, к тому же решающие одну задачу БП на однотипных предприятиях могут отличаться. Ввиду наличия таких фактов вводится понятие модели унифицированного бизнес-процесса (УБП), в котором будут отражены существенные независимые характеристики реальных бизнес-процессов предприятий [2].
Модель УБП состоит из двух частей «Последовательность операций» и «Операция». «Последовательность операций» представляет собой строгий алгоритм выполнения операций, который можно представить в виде блок_схем. Для построения такой модели необходимо выделить операции исполнителя. «Операция» - это модель, которая описывает каждый элемент УБП детально.
Рисунок 1.3. Блок-схема основной программы
Рисунок 1.4. Модель операции для операции 1
На основе УБП строится модель учебного унифицированного бизнес-процесса, которая представляет собой модель карты операций - дерева, состоящего из множества операций и множество точек принятия решений (ТПР). ТПР позволяет перейти от одной операции к другой, причем из одной точки можно перейти к нескольким операциям (рис. 1.5). Таким образом, получается иерархическая структура, каждая ветвь которой это возможный путь в ДИ [11].
Рисунок 1.5. Пример карты операций
Как видно из этих моделей, языки не отражают время операций, в связи с чем требуется изменение языков данных моделей с учетом времени. Для добавления времени в модели БП было решено использовать алгоритмы распределенного имитационного моделирования.
1.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].
Из рассмотренных выше алгоритмов можно сделать следующий вывод: все алгоритмы стараются поддерживать хронологический порядок событий, т.е. суть алгоритма заключается, во-первых, в обеспечении логического порядка наступления событий; во-вторых, в не нарушении временного фактора наступления событий. В СКДИ за логику выполнения отвечает ЛСА, в которой содержатся условия, переходы и осуществляемые операции, необходимо только, чтобы эти операции осуществлялись в соответствии со временем. Для этого были рассмотрены подходы продвижения времени в распределенном ИМ.
Распределенная модель, как было сказано выше, - это модель, состоящая из нескольких последовательных подмоделей, называемых логическими процессами, и одной коммуникационной подсистемы, которая реализует синхронизацию логических процессов. Логический процесс содержит собственные часы локального времени. После анализа алгоритмов распределенного ИМ следующим шагом было решено рассмотреть подходы к продвижению времени, используемые в имитационных системах. Существует три основных алгоритма управления временем:
1. Моделирование с фиксированным шагом.
2. Моделирование, управляемое событиями.
3. Моделирование, управляемое часами реального времени.
При реализации продвижения времени в системе первым способом состояние системы не зависит от наступления события, изменение состояния системы происходит через фиксированные промежутки времени [16, 19]. В каждый такт времени происходит проверка наличия запланированных событий в течение предыдущего интервала времени. Если на интервал были запланированы события, то считается, что эти события происходят в конце этого интервала (рис. 1.8). Проверка также выполняется, если на данный временной интервал событий запланировано не было. Если на проверяемый интервал запланированы два события с разным временем наступления, считается, что оба этих события произошли в конце интервала. Реальное событие можно «привязать» как к концу такта (его правой границе), так и к его началу (левой границе), что зависит от предпочтений или заданных условий [26]. Подход достаточно простой, но присутствует проблема, связанная с определением величины шага [19].
Второй способ предполагает случайный (или особый) шаг продвижения времени, который определяется наступлением событий. В качестве следующего значения часов модельного времени может выбираться событие с минимальной временной меткой. Если же известен закон распределения интервалов между событиями, шаг может определяться с помощью соответствующего датчика. Также при таком подходе могут наличествовать события, для выполнения которых в каждый квант времени необходимо вычислять логические условия, и, если такое условие истинно, событие выполняется.
Моделирование, управляемое часами реального времени, определяется синхронизацией модельного времени с процессорным, однако чаще здесь управление временем в системе зависит от скорости происходящих событий в реальном времени [16, 19].
Рисунок 1.8. Механизмы продвижения модельного времени, E1-7 - события
На рисунке представлены первые два подхода продвижения модельного времени, в некоторых источниках называемые «принцип дt» и «принцип дz», соответственно [26]. При моделировании с фиксированным промежутком времени в данном случае наступление событий приходится на конец такта. На рисунке показано как соотносится время с событиями. Как было сказано выше, дt - фиксированный, а дz - особый промежуток времени.
Изучив алгоритмы, а также подходы к реализации времени в распределенном ИМ, можно спроецировать имитационную модель на подсистему проведения ДИ.
1.4 Связь распределенного имитационного моделирования с ППДИ
Выполнение любых действий, требующих реакции, в подсистеме проведения деловых игр производится с помощью модуля «Активный ресурс», который должен реагировать на действия пользователя. Этот модуль выступит в качестве логического процесса, с которым будет взаимодействовать подсистема проведения ДИ. Активных ресурсов, взаимодействующих с ППДИ, может быть несколько, как и логических процессов, используемых при распределенном ИМ. Функции работы самой подсистемы, связанные со временем выполнения операций и событиями, возьмет на себя так называемая управляющая модель (УМ). Работу УМ можно сравнить с управляющей программой в распределенном ИМ, предназначенной для синхронизации логических процессов.
Как основные компоненты моделирования в подсистеме проведения ДИ можно выделить саму подсистему проведения и активные ресурсы, взаимодействие которых с ППДИ будет осуществляться с помощью сообщений. Т.е. вызов активного ресурса будет осуществляться во время выполнения операции, а результатом окончания работы АР будет сообщение подсистеме. Сообщение в рамках ППДИ - это событие, а событие - результат выполнения операции. События в имитационном моделировании - это мгновенное изменение состояния системы.
Предлагается событие сделать видом ресурса, однако события в ППДИ будут двух видов: входной ресурс-событие (РС) и выходной ресурс-событие. Такое разделение необходимо для осуществления управления временем в подсистеме. Входной РС будет знаком для начала выполнения операции, т.е. операция может начать выполняться при наличии входного РС, даже если не наступило время начала операции. Выходной ресурс-событие необходим для перехода к следующей операции. Выходной РС для одной операции является входным РС для другой. Наличие входного или выходного РС для каждой операции задается на этапе проектирования ДИ. Создание выходных РС обеспечивает гарантированный выход из состояния выполнения операции. Также при возникновении активных ресурсов в процессе выполнения операции бизнес-процесса необходимо, чтобы при окончании ЛСА каждого АР происходило формирование события, которое имеет значимость при выполнении операции в основной программе.
События (в нашем случае - операции) должны происходить в хронологическом порядке, т.е. следуя логике и времени. Как было сказано в параграфе 1.2.2, алгоритмы синхронизации модельного времени в распределенном ИМ в нашем случае не подходят, т.к. они учитывают и логику, и время. В СКДИ за логику выполнения отвечает ЛСА, значит, осталось разобраться со временем.
Выполнение операции начинается только тогда, когда есть входной ресурс-событие и текущее время меньше или равно времени наступления выполнения операции. При этом нужно определить, как будет осуществляться продвижение времени при разработке ППДИ. Из рассмотренных в параграфе 1.2.3 алгоритмов продвижения времени продвижение с фиксированным шагом не подойдет, т.к. такое моделирование не будет отражать главного: операция бизнес-процесса должна начать свое выполнение в ППДИ при наступлении времени начала операции, которое у всех операций разное. Моделирование, управляемое часами реального времени, не подойдет, т.к. СКДИ - это студия, содержащая деловые игры, с помощью которых пользователь может получить определенные навыки за короткое моделируемое время.
В таком случае отлично подойдет моделирование с продвижением времени при наступлении события (или на особые моменты времени, или при наличии условий), т.к. в подсистему будут добавлены события, наличие которых позволит перейти к следующей операции. Однако если не было сформировано выходного РС у одной операции, то следующая за ней операция не сможет начаться, т.к. она не будет иметь входного РС.
Физическое время выполнения операций будет задаваться на этапе проектирования ДИ, модельное время выполнения операций будет рассчитываться перед проведением игры, предварительно спросив игрока за какое время он хочет пройти эту игру. Информация о том, какие операции содержат какие входные и выходные ресурсы-события, задается на этапе проектирования деловой игры, как и информация о том, в каких операциях присутствует активный ресурс. Помимо активных ресурсов также на этапе проектирования деловой игры операции присваиваются и другие ресурсы.
Выполнение операции вместе с ее предусловием и постусловием можно представить в виде нескольких шагов:
1. Проверка операции и ресурсов на соответствие.
2. Проверка операции на наличие входного РС.
3. Формирование выходного РС.
4. Смена статусов ресурсов.
Выходом из состояния выполнения операции, как было сказано выше, будет точка «Формирование события».
По итогам проецирования элементов распределенного имитационного моделирования на подсистему проведения деловых игр, можно построить следующую таблицу (табл. 1.3):
Таблица 1.3. Проецирование распределенного ИМ на ППДИ
|
Характеристика / составляющие |
ППДИ |
Распределенное ИМ |
|
|
Компонент моделирования |
ППДИ, АР |
ЛП |
|
|
Объект действия |
Операция с событием |
Событие |
|
|
Список объектов |
Локальный (в ППДИ, в АР) |
Локальный (в ЛП) |
|
|
Часы модельного времени |
Локальные (в ППДИ, в АР) |
Локальные (в ЛП) |
|
|
Программа синхронизации компонентов моделирования |
Управляющая модель в ППДИ |
Коммуникационная подсистема |
|
|
Взаимодействие программы синхронизации с компонентами моделирования |
УП - часть ППДИ. Общение АР с ППДИ с помощью сообщения, ППДИ с АР - программный вызов |
Взаимодействие ЛП с коммуникационной системой с помощью интерфейса. Между ЛП - обмен сообщениями |
|
|
Логическая последовательность объектов |
Содержится в ЛСА |
Содержится в коммуникационной подсистеме |
Таким образом, определив основные составляющие рассматриваемой подсистемы и обозначив принцип управления временем, следующим шагом необходимо разработать требования к программе, а также новые алгоритмы управления частями ППДИ.
2. Проектирование подсистемы проведения деловых игр с учетом продвижения времени
В данной главе будут представлены требования к программе, определены алгоритмы: алгоритм взаимодействия пользователя с подсистемой проведения ДИ, алгоритм работы самой ППДИ, алгоритм работы модуля «Активный ресурс». Принцип взаимодействия подсистемы проведения ДИ с модулем отражен в диаграмме последовательностей. Разработка таких алгоритмов обусловлена добавлением времени и событий в ППДИ. Также в данной главе описано изменение языка моделей бизне СКДИ.
2.1 Разработка требований
Основываясь на требованиях, предъявляемых к данному программному продукту в [12, 13] и добавив возможность настройки и моделирования времени, можно разработать следующие функциональные требования к подсистеме проведения ДИ:
1. Пользователь должен иметь возможность задавать модельное время прохождения игры.
2. Управляющая модель выполняет перерасчет физического времени операций на модельное.
3. Автоматная модель выделяет команду из ЛСА.
4. Автоматная модель отправляет команду ОМ.
5. Операционная модель получает команду, выводит на экран все доступные для выполнения очередной операции ресурсы из БД согласно команде.
6. Пользователь должен иметь возможность выбирать ресурсы.
7. ОМ формирует условие, соответствующее действиям пользователя.
8. ОМ проверяет выбранные ресурсы на наличие операции в БД.
9. ОМ отправляет условие управляющей модели.
10. УМ проверяет операции на наличие в БД, на время, на наличие активных ресурсов и ресурсов-событий.
11. УМ формирует выходной ресурс-событие.
12. УМ отправляет условие АМ.
13. АМ принимает условие, выполняет поиск ЛСА в БД, выделяет из нее команду.
14. АМ отправляет команду ОМ.
15. УП проверяет конец времени операции.
16. Пользователь должен иметь возможность получения результата выполнения операции или ошибки после нажатия на кнопку «Выполнить операцию».
17. АМ по условию переходит к п. 3.
2.2 Разработка алгоритма взаимодействия пользователя с ППДИ
Перед тем, как определить функциональные требования, предъявляемые к программе, можно разработать алгоритм взаимодействия игрока с системой с учетом времени:
1. Пользователь задает модельное время прохождения игры.
2. Система производит перерасчет физического времени операций на модельное.
3. Система выводит на экран все доступные для выполнения очередной операции ресурсы согласно ЛСА.
4. Пользователь выбирает ресурсы.
5. Пользователь нажимает на кнопку «Выполнить операцию».
6. Пользователь ждет результата от системы.
7. Система сообщает о результате выполнения операции или об ошибке.
8. Пока не конец игры, повторять п. 3-7.
2.3 Разработка алгоритма работы ППДИ
При разработке алгоритма работы ППДИ с проверкой времени и формированием событий необходимо учесть следующие моменты:
· Работу, связанную с событиями и временем, выполняет управляющий модуль.
· Начать выполнение операции можно только если у операции есть входной ресурс-событие и текущее время меньше или равно времени наступления этой операции, иначе конец игры.
· Наличие входного РС означает, что он был сформирован в предыдущей операции (кроме первой операции - в начале игры входным РС является событие «Игра началась»).
· Длительность операции - максимально возможный промежуток времени, который она может продолжаться. Операция может завершиться до того, как время выполнения операции закончилось, если был сформирован выходной ресурс-событие.
· Выходной РС формируется при окончании выполнения операции, если не был сформирован ранее.
· Ресурс может быть не доступен для выбора пользователем, может быть доступен и может быть выбран. Статус доступных ресурсов помечается как «0» (ноль), выбранных- как «1» (единица), всех остальных - «-» (прочерк) или «» (пустота, null).
Алгоритм работы ППДИ, разделенный на работу отдельных модулей, выглядит следующим образом:
1. АМ выполняет запрос к БД, загружает ЛСА.
2. АМ выделяет команду с первой моделью сцены.
3. АМ отправляет команду ОМ.
4. ОМ получает команду, выводит на экран все доступные для выполнения очередной операции ресурсы согласно ЛСА.
5. ОМ формирует условие, отвечающее действиям пользователя, для перехода к следующей сцене. Лист ресурсов обновляется после выбора ресурсов игроком: ресурсы, которые выбрал пользователь, меняют статус с «0» на «1».
6. ОМ выполняет запрос к БД, проверяет выбранные ресурсы на наличие операции, имеющей на входе такой набор входных ресурсов: если такая операция в есть, то переход к п. 7; если такой операции найдено не было, то на экран игроку выводится сообщение с информацией об ошибке, переход к п. 8.
7. Выполнение операции:
7.1. УМ проверяет наличие входного ресурса-события в операции и проверяет время: если есть входной ресурс-событие и текущее время меньше или равно времени начала операции, то переход к п. 7.2, иначе вывод сообщения об ошибке, переход к п. 8.
7.2. УМ формирует выходной ресурс-событие.
7.3. ОМ отправляет условие, содержащее статусы ресурсов, АМ.
7.4. АМ принимает условие, выполняет запрос к БД.
7.5. АМ находит ЛСА, выделяет команду (со следующей моделью сцены) из ЛСА.
7.6. АМ отправляет команду ОМ. Смена статусов ресурсов: входные ресурсы становятся недоступными (статус «-»); выходные ресурсы становятся доступными (статус «0»).
7.7. УМ проверяет время, выделенное на выполнение операции: если время не закончилось, то переход к п. 8, иначе на экран игроку выводится сообщение с информацией об ошибке, переход к проверке конца игры.
8. Пока не конец игры, повторять п. 4-7.
Алгоритм работы ППДИ наглядно представлен ниже в виде блок-схемы на рисунках 2.1, детализация блока «Выполнение операции» - на рисунке 2.2.
Рисунок 2.1. Алгоритм работы ППДИ
Рисунок 2.2. Алгоритм работы ППДИ: детализация блока «Выполнение операции»
2.3 Разработка алгоритма работы АР
При разработке такого алгоритма необходимо учесть следующие моменты:
· Если есть активные ресурсы, то ЛСА каждого АР выполняется одновременно с ЛСА ППДИ. Как только нашелся в БД очередной АР у операции, сразу включается в работу ЛСА этого АР. Получается, что ЛСА каждого АР операции включается в работу последовательно. Тогда ЛСА всех активных ресурсов и ППДИ будут выполняться в разных потоках одновременно.
· Если есть АР и сообщения пришли от всех АР, тогда можно сформировать событие раньше, чем закончится выполнение операции.
· Если сообщения пришли не от всех АР, то нужно ждать сообщения от всех, пока не закончится время на выполнение операции.
Выполнение АР происходит на этапе выполнения операции при наличии АР у операции. Тогда блок-схему (рис. 2.2) можно дополнить так, как изображено на рисунке 2.3 (начало) и 2.4 (продолжение). Алгоритм будет следующим:
1. ОМ выполняет запрос к БД, проверяет на использование в операции активного ресурса: если в операции задействован активный ресурс (активные ресурсы), то АМ загружает ЛСА АР, иначе переход к проверке конца игры.
2. УМ проверяет наличие сообщений от всех АР: если есть в наличии сообщения от всех активных ресурсов, задействованных в операции, переход к формированию события, если в наличии сообщения не от всех активных ресурсов, то переход к следующему пункту (п. 3).
3. УМ проверяет время, выделенное на выполнение операции: если время не закончилось, то УМ ждет сообщения, переход к п. 2, иначе на экран игроку выводится сообщение с информацией об ошибке, переход к проверке конца игры.
Рисунок 2.3. Алгоритм работы модуля «АР» (начало)
Рисунок 2.4. Алгоритм работы модуля «АР» (продолжение)
Взаимодействие между ППДИ и АР будет представлено ниже в виде диаграмм последовательностей.
2.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
Модели операций для АР также содержат дополнительные параметры как модели операций для основной программы (время начала, время выполнения, событие), однако заполнение этих моделей будет происходить в учебном унифицированном БП, т.к. активных ресурсов одного типа может быть несколько и каждый будет иметь определенную модель поведения.
Подобные документы
Особенности управления сложными технологическим комплексами с использованием рефлексивных компьютерных игр. Характеристика двухэтапной процедуры организации обучения малой группы специалистов. Способы построения сюжета исходного тестового изображения.
реферат [66,0 K], добавлен 14.08.2013Изучение работы с деловыми экономическими играми, оформленными в программе Excel и позволяющими более эффективно проводить уроки экономики. Описание и цели игр: "Турагентство "Вояж", "У озера", "Арбузы"; их основные концепции, инструкции и окно решения.
научная работа [31,9 K], добавлен 05.02.2011Компьютерные обучающие системы. Принципы новых информационных технологий обучения. Типы обучающих программ. Активизация обучения. Компьютерное тестирование. Перспективные исследования в области компьютерного обучения. Интернет-технологии, мультимедиа.
контрольная работа [60,3 K], добавлен 10.09.2008Организационно-административное обеспечение информационной безопасности. Процедура санкционирования в отношении средств информации. Классификация ресурсов и контроль за ними. Неформальные методы поиска оптимальных решений. Управление защитой информации.
учебное пособие [969,6 K], добавлен 18.01.2011Исследование общих правил игры в шашки, инструкции пользователя и программиста. Характеристика основных алгоритмов, исполняющих задачи класса Life Widget. Оценка ходов компьютера и человека. Построение дерева поиска лучшего хода исходя из оценки функций.
контрольная работа [1,3 M], добавлен 20.12.2012Анализ учебно-методической литературы. Моделирование системы знаковых средств обучения. Топология компьютерных сетей. Правила сетевого взаимодействия. Кабели на основе витых пар. Конструирование средств тематического контроля. Аппаратура локальных сетей.
курсовая работа [1,7 M], добавлен 07.06.2016Матричные игры и линейное программирование. Итеративный метод решения матричных игр. Игры на выживание, игры-погони. Критерии принятия решений. Персонал, набранный с помощью резерва в результате решения статистической игры по различным критериям.
курсовая работа [629,3 K], добавлен 08.10.2014Первые примитивные компьютерные и видеоигры. Обзор современных компьютерных игр. Классификация по количеству игроков. Обзор контроллеров. Исследование психологической зависимости человека от ролевых компьютерных игр. Динамика развития зависимости.
дипломная работа [76,9 K], добавлен 18.08.2013Обзор существующий решений в области электронного обучения. Исследование архитектурных и технологических аспектов построения виртуальных корпоративных университетов. Анализ возможностей системы дистанционного обучения Sakai, отличительные особенности.
дипломная работа [2,7 M], добавлен 09.04.2011Классификация методов анализа по группам. Сбор и хранение необходимой для принятия решений информации. Подготовка результатов оперативного и интеллектуального анализа для эффективного их восприятия потребителями и принятия на её основе адекватных решений.
контрольная работа [93,2 K], добавлен 15.02.2010
