ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ Пермский филиал федерального государственного автономного образовательного

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
Пермский филиал
федерального государственного автономного образовательного
учреждения высшего профессионального образования
"Национальный исследовательский университет
"Высшая школа экономики"
Факультет бизнес-информатики
Кафедра информационных технологий в бизнесе
УДК 004.94
РАЗРАБОТКА ОПЕРАЦИОННОЙ МОДЕЛИ
ПРОГРАММНОГО КОМПЛЕКСА ДЛЯ ПРОВЕДЕНИЯ
ДЕЛОВЫХ ИГР
Выпускная квалификационная работа бакалавра
Работу выполнила студентка
группы БИ-10-2
4 курса факультета бизнес-информатики
Голева Е.А.
Научный руководитель:
к.т.н., доцент кафедры информационных
технологий в бизнесе
Викентьева О.Л.
“_____”
Пермь 2014
2014 г.
ОГЛАВЛЕНИЕ
Список терминов и сокращений ...................................................................................... 3
Введение ............................................................................................................................. 4
Глава 1. Анализ систем (моделей) разработок для деловых игр .................................. 7
1.1 Основные понятия для разработки и проектирования операционной модели
Студии компетентностных деловых игр ......................................................................... 7
1.2 Обзор и анализ существующих автоматизированных деловых игр .................... 12
1.3 Описание подсистем Студии компетентностных деловых игр ............................ 13
1.4 Модель прецедентов для операционной модели .................................................... 15
1.4.1 Документирование прецедентов ........................................................................... 17
1.4.2 Моделирование видов деятельности .................................................................... 19
Глава 2. Проектирование операционной модели ......................................................... 27
2.1 Проектирование базы данных .................................................................................. 27
2.1.1 Концептуальная модель данных ........................................................................... 27
2.1.2 Логическая модель данных.................................................................................... 28
2.1.3 Физическая модель данных ................................................................................... 31
2.2 Проектирование макетов форм ................................................................................ 34
Глава 3. Разработка операционной модели................................................................... 39
3.1 Средства, использованные для осуществления интеграции операционной и
автоматной моделей ........................................................................................................ 39
3.2 Алгоритм проведения игры для подсистемы проведения ..................................... 39
3.3 Разработка форм игры ............................................................................................... 43
3.4 Контрольный пример ................................................................................................ 46
Заключение ....................................................................................................................... 51
Библиографический список ............................................................................................ 52
Приложение A. Сравнение автоматизированных деловых игр .................................. 53
Приложение B. Экономическое обоснование .............................................................. 54
Приложение C. Техническое задание ............................................................................ 59
Приложение D. Руководство пользователя .................................................................. 78
2
СПИСОК ТЕРМИНОВ И СОКРАЩЕНИЙ
СКДИ
-
Студия компетентностных деловых игр
ОМ
-
Операционная модель
АМ
-
Автоматная модель
ОА
-
Операционный автомат
УА
-
Управляющий автомат
ДИ
-
Деловая игра
КДИ
-
Кометентностная деловая игра
ЛСА
-
Логическая схема алгоритма
БД
-
База данных
ИИС
-
Интеллектуальная информационная система
БП
-
Бизнес-процесс
РБП
-
Рабочий бизнес-процесс
КО
-
Карта операций
Оп
-
Операции
ТПР
-
Точка принятия решений
ТЗ
-
Техническое задание
3
ВВЕДЕНИЕ
В работе рассматривается разработка программного модуля операционной
модели,
которая
является
частью
программного
комплекса
Студии
компетентностных деловых игр. Студия компетентностных деловых игр – это
инструментальная среда, обеспечивающая формирование компетенций Игрока.
Формирование компетенций происходит в процессе выполнения действий
рабочего бизнес процесса. Рабочий бизнес-процесс отражает существенные
характеристики реальных бизнес-процессов, протекающих в организации. Для
формализации рабочего бизнес-процесса используется понятие Учебного
бизнес-процесса, включающего в себя карту операций, операции, точки
принятия решений.
Исходными данными для операционной модели является код сцены
деловой игры, которую формирует управляющий автомат (автоматная модель)
на основании сценария деловой игры. По коду сцены операционная модель
находит в базе данных деловой игры необходимые для этой сцены ресурсы и
отображает их на экране. После получения реакции пользователя на
сформированную моделью сцену, операционная модель меняет текущее
состояние игры и передает его при помощи регистра состояния автоматной
модели, которая в зависимости от состояния игры будет формировать код
следующей сцены деловой игры.
Ресурсы игры – это программные объекты, которые используются для
имитации
бизнес-процесса,
выполняемого
Игроком
для
получения
определенных компетенций. В качестве ресурсов могут выступать диалоговые
окна, осуществляющие взаимодействие с Игроком и файлы различных типов,
содержащие
информацию.
необходимую
К
для
моменту
выполнения
проведения
заданного
игры
ресурсы
бизнес-процесса
должны
быть
спроектированы разработчиками, и информация о ресурсах помещена в таблицы
базы данных.
Задачами операционной модели являются: получение команды из
автоматной модели (идентификатора следующей сцены), выбор из базы данных и
размещение действий на форме, формирование формы взаимодействия с
ресурсами (в соответствии с выбранным Игроком действием), вычисление
4
текущего состояния игры и изменение регистра состояния игры, в зависимости
от реакции Игрока на сложившуюся игровую ситуацию.
По сравнению со стандартными подходами к обучению (например,
лекционными занятиями, тестами или практическими заданиями), организация
процесса обучения через игру является более наглядным способом получения
компетенций.
Использование
игр
для
обучения
получило
термин
«геймификация» [1]. С помощью Студии компетентностных деловых игр
предполагается разрабатывать и проводить бизнес-игры, которые обеспечивают
следующие преимущества:
1. Виден прогресс Игрока: на каждом этапе игры оценивается уровень
компетенций Игрока, в конце игры вычисляется суммарный уровень
компетенций.
2. Выполняются задания с различной структурой: разнообразие заданий
для Игрока определяется ресурсами, которые будут разработаны.
3. Поощрение Игрока: ход игры зависит от результата Игрока на текущем
этапе (например, если Игрок выполнил правильно сложное задание,
то ему присваивается оценка выше или «штраф» меньше).
4. Наличие обратной связи от Игроков для корректировки деловой игры.
5. Универсальность: Студия компетентностных деловых игр может
использоваться
не
только
студентами,
но
и
коммерческими
организациями для обучения персонала.
6. Адаптивность игры: имеется возможность реализовать выполнения
сценария деловой игры с учетом полученных игроком компетенций,
например, можно повторить задания, в которых уровень полученных
компетенций оказался меньше заданного.
7. Студия
компетентностных
деловых
игр
может
дополняться
программными модулями, отвечающими за функционал игры.
Необходимость разработки Студии компетентностных деловых игр
вызвана тем, что в современных автоматизированных деловых играх нет
возможности отслеживать динамику Игрока в ходе самой игры (на различных
этапах). Следовательно, если результат Игрока оценивается только в конце игры,
то и возможность повлиять на ход игры и настроить её под уровень текущих
5
компетенций Игрока отсутствует. Студия компетентностных деловых игр
предполагает встроенный в подсистему проведения механизм поэтапной оценки
уровня компетенций Игрока и адаптации уровня сложности игры под его
текущий уровень компетенций.
Процесс
оценивания
Игроков
является
автоматизированным
и
объективным. Помимо этого, Студия компетентностных деловых игр позволит
разрабатывать прототипы моделей (тренажёры). Тренажёры часто используются
для обучения в тех случаях, когда какой-то процесс (опыт и т. п.) достаточно
сложно или невозможно воссоздать в реальной жизни.
Объектом исследования является интеллектуальная информационная
система
для
исследования
проведения
является
компетентностных
операционная
деловых
модель
игр.
Предметом
интеллектуальной
информационной системы. Цель выпускной квалификационной работы –
разработка программного модуля, который обеспечит выполнение функций
операционной модели Студии компетентностных деловых игр.
Для достижения поставленной цели были сформулированы следующие
задачи:
1. Обзор и сравнение систем для проектирования и проведения деловых
игр.
2. Определение функциональных требований к операционной модели.
3. Проектирование базы данных для подсистемы проведения.
4. Проектирование диалоговых форм.
5. Реализация операционной модели на языке программирования высокого
уровня.
6. Разработка
технической
(представлено
в
документации
приложении C)
(представлено в приложении D).
6
и
-
технического
руководства
задания
пользователя
ГЛАВА 1. АНАЛИЗ СИСТЕМ (МОДЕЛЕЙ) РАЗРАБОТОК ДЛЯ
ДЕЛОВЫХ ИГР
1.1 Основные понятия для разработки и проектирования
операционной модели Студии компетентностных деловых игр
Перед тем как приступить к описанию составляющих, которые будут
входить в программный модуль, реализующий операционную модель СКДИ,
следует выделить ключевые понятия.
СКДИ является интеллектуальной системой, поэтому, прежде всего,
следует определить, что такое интеллектуальная информационная система.
Первое
определение
дано
Трофимовой Л.А.
и
Трофимовым В.В.:
«Интеллектуальная информационная система (ИИС) - комплекс программных,
лингвистических и логико-математических средств для реализации основной
задачи – осуществления поддержки деятельности человека и поиска информации
в режиме продвинутого диалога на естественном языке» [2]. СКДИ включает в
себя набор модулей, реализующих основную задачу – обучение Игрока. Диалог с
Игроком организован с помощью разработанных в операционной модели
диалоговых окон, вызываемых в результате действий Игрока. В случае если
Игрок повторяет ошибки, на экранной форме (сцене) появляются подсказки о
том, какие действия следует предпринять или какой материал требуется
повторить. Логико-математические правила, отвечающие за протекание процесса
игры, реализуются в автоматной модели.
Другое определение дано К.Кришнакумару, интеллектуальные системы это: «Nature-inspired, mathematically sound, computationally intensive problem
solving tools and methodologies that have become extremely important for advancing
the current trends in information technology. An intelligent system is a system that
emulates some aspects of intelligence exhibited by nature. These include learning,
adaptability, robustness across problem domains, improving efficiency (over time
and/or space), information compression (data to knowledge), extrapolated reasoning»
[3].
В основе СКДИ лежит деловая игра. Если давать определение ДИ более
обобщённо, то можно воспользоваться определением, данным Робертом
7
Виллсом: «They provide an experiential framework for learning and applying
concepts learned, add interest and even excitement to the classroom and provide a risk
free environment for learning» [4].
Каждая деловая игра является симулятором некого бизнес-процесса, по
которому в дальнейшем строится сценарий. Целью деловой игры является
получение Игроком компетенций в предметной области, для которой была
разработана деловая игра. Под компетенцией понимается умение применять
теоретические знания, которые Игрок получает через взаимодействие с
игровыми ресурсами, на практике.
Если рассматривать ДИ как составляющую СКДИ, то согласно другому
определению, приведённому в статье «The construction of competency-based
business game operational model»: «Компетентностная деловая игра – это
информационная система, целью которой является получение определенного
уровня профессиональных компетенций в процессе реализации сценариев,
определяемых моделями бизнес-процессов предметной области» [5].
Компетентностная деловая игра является интерактивной разновидностью
процесса обучения
и
состоит из
двух составляющих:
технической и
организационной.
Техническая составляющая КДИ включает в себя множество транзакций,
которые направлены на формирование у Игрока компетенций. На уровне
технической составляющей производится декомпозиция КДИ на автоматную
(управляющую) и операционную модели, которые являются частями подсистемы
проведения, предназначенной для проведения деловой игры с использованием
сцен и сценариев игры, разработанных в подсистеме.
Операционная и автоматная модели строятся на основе модели
В. М. Глушкова
[6],
которая
является
конкретизацией
модели
системы
управления применительно к дискретным преобразователям информации и
включает в себя два блока: операционный автомат и управляющий автомат [7].
Выходы ОА – это логические сигналы, которые получаются в результате
преобразования и поступают на вход УА, после чего УА генерирует
последовательность
управляющих
сигналов.
8
Управляющие
сигналы
отправляются в ОА, под их воздействием происходит преобразование входных
сигналов в выходные в соответствии с алгоритмом, хранящимся в УА.
Операционный автомат выполняет операции и вычисляет значения
логических
условий,
которые
возникают
при
обработке
этапов
игры.
Управляющий автомат определяет последовательность выполнения действий в
операционном автомате, которая формируется исходя из алгоритма выполнения
операций.
ОА является структурой, выполняющей действия над информацией или
командами. Операции, выполняемые ОА, задаются множеством управляющих
сигналов 𝑌 = {𝑦1 , … , 𝑦𝑀 }, каждый управляющий сигнал представляет собой
определенную операцию. Значения логических условий, вычисляемые в
операционном
автомате,
отображаются
множеством
осведомительных
сигналов 𝑋 = {𝑥1 , … , 𝑥𝐼 }, каждый из которых - определенное логическое условие.
Функция ОА задаётся следующим набором следующих множеств:
1. Множество входных слов 𝐷 = {𝑑1 , … , 𝑑𝐻 }, вводимых в автомат в
качестве операндов.
2. Множество
выходных
слов 𝑅 = {𝑟1 , … , 𝑟𝑄 },
представляющих
результаты операций.
3. Множество
внутренних
слов 𝑆 = {𝑠1 , … , 𝑠𝑁 },
используемых
для
представления информации в процессе выполнения операций (можно
считать, что входные и выходные слова совпадают с определенными
внутренними).
4. Множество операций 𝑌 = {𝑦𝑚 }, реализующих преобразование 𝑆 =
𝑗𝑚 (𝑠) над словами информации, где 𝑗𝑚 — вычисляемая функция.
5. Множество логических условий 𝑋 = {𝑥𝑖 }, где 𝑥𝑖 = 𝑦𝑖 (𝑠𝑖 ), а 𝑦𝑖 — булева
функция; это i-ое условие из множества всех условий. Эта запись
проверяет выполнение условия 𝜑𝑖 над множеством слов S. Если
условие выполняется, то 𝑥 = 1, иначе 𝑥 = 0.
Функция
ОА
считается
заданной,
если
определено
каждое
из
множеств D, R, S, Y, X. Время не является аргументом функции ОА, так как
функция ОА определяет набор операций и логических условий, которые могут
выполняться ОА, но не последовательность их выполнения во времени. С
9
помощью этой функции нельзя описать вычислительный процесс, можно лишь
определить средства, которые будут использоваться в вычислительном процессе.
Для того чтобы описать бизнес-процесс, поступающий из подсистемы
проектирования в подсистему проведения, в частности в управляющий автомат,
используется
язык
Логических
Схем
Алгоритмов,
разработанный
А.А.
Ляпуновым. Описание составляющих ЛСА приведено далее: «Логическая схема
представляет собой строку из операторов и логических условий, называемых
членами схемы. После каждого логического условия начинается стрелка,
оканчивающаяся перед одним из членов схемы, либо в конце строки» [8].
Операционный автомат отвечает за отображение ресурсов, Управляющий
автомат обеспечивает реализацию сценария деловой игры. Последовательность
выполнения операций (сценария) записывается с помощью строки ЛСА и
является одной из форм для записи бизнес-процесса. При выполнении
последовательности операций из БП, в ОМ из АМ поступают сцены, в которых
содержится информация о ресурсах и операциях (действиях), которые можно
совершить на текущем шаге.
В СКДИ для представления бизнес-процесса в игровой форме будут
применяться подходы, характерные компьютерным играм. Разработанная по
требованиям заказчика деловая игра представляет собой некий сценарий. Под
сценарием деловой игры понимается ход развития событий внутри игры, для
деловой игры сценарий будет описан в виде бизнес-процесса. Бизнес-процесс
или сценарий включает в себя набор точек принятия решения (сцен). В игре
существует четыре базовые формы: стартовая, форма выбора действия, форма
обращения к ресурсу (ресурсам), конечная форма. В стартовой форме Игрок
выбирает ДИ из списка разработанных ДИ. В форме выбора действия
располагаются действия, которые может совершить Игрок на данном этапе игры.
В форме обращения к ресурсу Игрок может выбрать инструменты, необходимые
для исполнения выбранного ранее действия. В конечной форме Игроку
выводится его результат (текущий уровень компетенций), который вычисляется
по ходу игры.
Наполнением всех форм, за исключением стартовой и конечной, будут
являться действия и/или ресурсы игры. Действие описывает некий процесс,
10
который является составляющей бизнес-процесса, действие изображается на
сцене выбора действий с помощью кнопки или пункта меню. Ресурсом является
инструмент, с помощью которого может быть выполнено действие, им может
быть файл, изображение, кнопка и другие стандартные объекты из набора
инструментов для проектирования форм с помощью WinForms.
Форма взаимодействия с ресурсами поделена на 4 блока: входы, выходы,
управление, механизмы. Входами являются файлы для ознакомления Игроком,
данные файлы не доступны для редактирования, осуществляется только чтение
файла. Примером входа может быть изображение с иллюстрацией к заданию.
Ресурсами в блоке управления также являются файлы для чтения (чаще всего
файлы, содержащие текст в формате pdf, doc, xls и т. п.). Отличие ресурсов в
блоке входов от ресурсов блока управления состоит в том, что под управлением
понимаются документы, распоряжения, любые другие документы, влияющие
на порядок и ход выполнения действия (процесса). Примером ресурса в блоке
управления может быть должностная инструкция, описанная в файле с форматом
doc. Механизмом — это команда, необходимая для выполнения действия
(процесса). Например, если Игрок выбирает действие «написать ТЗ», в качестве
механизма будет системная команда, которая запускает Microsoft Office Word
2010. Выходами являются файлы, которые предназначены для редактирования и
сохраняются Игроком после взаимодействия с ними.
Использование
ДИ
в
учебном
процессе
реализует
принципы
«геймификации» (использование игровых механизмов в неигровых сферах) для
повышения интереса пользователей к процессу обучения. По прогнозам
компании «Gartner» [9] 40% из списка «Global 1000 organizations» к 2015 году
будут использовать в своей работе «геймификацию» - комплекс мотивационных
управленческих техник, заимствованных у компьютерных игр. Для реализации
бизнес-процессов
в ДИ с помощью логико-математических правил будет
использована операционная модель, для представления хода игры в автоматной
модели будет использован язык логических схем алгоритмов.
11
1.2 Обзор и анализ существующих автоматизированных деловых игр
Для того чтобы выполнить обзор и сравнить существующие деловые
игры, необходимо провести их анализ. В качестве объекта для анализа выбрана
автоматизированная деловая игра.
Для анализа аналогов СКДИ на российском рынке были выбраны
следующие автоматизированные ДИ: SimVenture и Simultrain. При проведении
анализа использовалось сравнение игр по критериям, показателям, индикаторам
(см. прил. A).
Критерием является признак, по которому производится оценка или
классификация игр. Для автоматизированных деловых игр можно выделить
следующие критерии:
1. Диалог с пользователем.
2. Команды управляющей модели.
3. Стоимости лицензий.
4. Встроенные БП.
5. Рейтинг игрока.
6. Тип доступа к игре.
С помощью показателя может быть задана количественная оценка
критерия. Ниже приведён список показателей для каждого критерия:
1. Диалог с пользователем:
a. Интуитивно понятный интерфейс.
b. Предупреждение об ошибках.
c. Мультиязычность.
2. Команды управляющей модели:
a. Расширяемость команд.
b. Адаптивность игры к результатам игрока.
3. Стоимости лицензий:
a. Бесплатные демо-версии.
b. Есть ли срок лицензии.
c. Наличие скидок.
4. Встроенные БП:
a. Управляющие.
12
b. Операционные.
c. Поддерживающие.
5. Рейтинг игрока:
a. Наличие встроенного механизма оценивания.
b. Ранжирование игроков.
c. Бонусы за лидерство.
6. Тип доступа к игре:
a. Для ВУЗов.
b. Корпоративный.
c. Для физических лиц.
Индикаторы используются для того, чтобы указать наличие или
отсутствие критерия для рассматриваемой деловой игры. Условное обозначение
для наличия критерия в ДИ «+», для отсутствия критерия в ДИ «-».
Анализ аналогов СКДИ проводился с целью выявления функционала,
который является частью автоматизированных ДИ конкурентов, но отсутствует
в СКДИ. С помощью анализа было выявлено, что в СКДИ отсутствует
мультиязычность (игра предоставляется только на русском языке), что
неприемлемо при нацеленности на международный рынок ДИ. Кроме того,
несмотря на то, что в СКДИ предполагается наличие встроенного механизма
оценивания достигнутого Игроком уровня компетенций, отсутствуют бонусы за
лидерство. В СКДИ действует система штрафов, что с психологической точки
зрения является анти-стимулом Игрока. Большим недостатком СКДИ является
направленность на развитие механизмов системы, а не на взаимодействие с
Игроком.
1.3 Описание подсистем Студии компетентностных деловых игр
СКДИ состоит из шести подсистем:
1. Подсистема проектирования.
2. Подсистема проведения.
3. Подсистема мониторинга.
4. Подсистема измерения.
5. Подсистема анализа.
6. Подсистема корректировки.
13
Подсистема проектирования отвечает за приведённые ниже функции:
1. Проектирование сценариев на начальном этапе разработки ДИ.
2. Перепроектирование сценариев, если подсистемой корректировки
были выявлены недочёты в сценарии ДИ.
3. Разработку сценариев деловых игр.
Пользователем ответственным за проектирование и разработку сценариев
является проектировщик БП. Подсистема проектирования взаимодействует с
подсистемой проведения и подсистемой корректировки. Помимо создания
сценариев, в данной подсистеме происходит заполнение базы данных
исходными данными (ресурсами), поступающими от Заказчика.
Подсистема проведения предназначена для проведения деловой игры,
которое осуществляется встроенными в неё операционной и автоматной
моделями. Для своей работы подсистема использует материалы, разработанные
ранее в подсистеме проектирования, а также данные необходимые для
проведения автоматизированной ДИ, хранящиеся в БД СКДИ. Подсистема
проведения взаимодействует с подсистемами мониторинга и подсистемой
измерения.
Основной задачей подсистемы мониторинга является отслеживание хода
игры и результатов Игроков. В подсистеме мониторинга осуществляется
отслеживание корректности заполнения данных Игроком или сравнение
реального ответа Игрока с эталонным ответом, хранящимся в БД СКДИ.
Подсистема
мониторинга
взаимодействует
с
подсистемой
измерения
и
подсистемой анализа.
Подсистема измерения использует контрольно-измерительные материалы,
позволяющие
определить
уровень
сформированных
компетенций.
Взаимодействует с подсистемой мониторинга и подсистемой проектирования.
Подсистема
анализа
предназначена
для
обработки
результатов,
полученных в ходе игры. Помимо этого, в ее обязанности входит получение
отчетов о качестве методического обеспечения. Взаимодействует с подсистемой
корректировки и подсистемой мониторинга.
Подсистемы
корректировки
отвечает
за
оперативную
оценку
корректности хода деловой игры (разработанного сценария ДИ). Кроме того, в
14
обязанности подсистемы входит разработка технической документации для
доработки уже созданных сценариев ДИ. Подсистема взаимодействует с
подсистемой анализа, подсистемой проведения и подсистемой проектирования.
Более подробное разделение СКДИ на подсистемы, а также порядок
взаимодействия подсистем приведены на рисунке 1.1:
Рисунок 1.1. Подсистемы Студии компетентностных деловых игр
1.4 Модель прецедентов для операционной модели
Модель прецедентов описывает функциональные требования к СКДИ и
используется в качестве модели «to be». Каждая описанная функция является
результатом выявления ценных для субъекта задач. Чтобы определить задачи
субъекта необходимо определить, какие функции или действия субъект
выполняет по отношению к системе и что он хочет получить в результате
взаимодействия с системой. Распределение функциональных требований по
субъектам и прецедентам приведено в таблице 1.1:
№
1
2
Таблица 1.1. Распределение требований по субъектам и прецедентам
Требование
Субъект
Прецедент
На
экран
Игроку
выводится Игрок
Выбор ДИ в стартовой
стартовая сцена со списком деловых
сцене
игр, Игрок делает выбор деловой
игры.
Для
принятия
решения
о Игрок
Выбор действия на
дальнейшем ходе развития игры,
сцене действий
Игрок должен выбрать действие на
сцене. Несколько действий на сцене
символизируют наличие условного
оператора if, если действие одно, то
15
№
3
4
5
6
7
8
Требование
наличие выбора в связи с условием
игры не предполагается (действие
выбирается по умолчанию, сцена
выбора
действий
игроку
не
выводится, выбранное действие
будет выведено Игроку в сцене
взаимодействия с ресурсами).
Сцене игры может принадлежать
ресурс или набор ресурсов, с
которыми может взаимодействовать
Игрок. Например, для выполнения
ремонтных работ Игрок – «маляр»
может обратиться к следующим
ресурсам: кисть, валик, план работ.
Некоторые сцены не предполагают
наличия
ресурсов,
например,
стартовая и конечная сцены игры.
Состояние
игры
определяется
значением условия перехода к
следующей
сцене,
которое
определяется при выборе действия
Игроком.
Сцена – является точкой принятия
решения, в сцене выбора действия
Игрок должен совершить (выбрать)
действие.
Действия
сцены
выбираются из БД СКДИ по
идентификатору сцены. Выбранные
из
БД
СКДИ
действия
располагаются на сцене.
Из БД СКДИ на сцену по
идентификатору сцены выбираются
ресурсы. Ресурсы располагаются в
соответствующем категории ресурса
блоке (управления, входов, выходов,
механизмов). Выбранные из БД
СКДИ ресурсы располагаются на
сцене.
После того, как Игрок закончил своё
взаимодействие
со
сценой
последовательность
переходов,
проделанная Игроком в сцене,
кодируется с помощью двоичного
кода и записывается в регистр
состояний игры.
Операционная модель получает из
регистра состояний идентификатор
сцены, которую необходимо вывести
Игроку на экран.
Субъект
Прецедент
Игрок
Обращение к ресурсу
(ресурсам) в сцене
взаимодействия
с
ресурсами
Игрок
Вычисление
состояния игры
БД СКДИ
Вывод сцены выбора
действий на экран
БД СКДИ
Вывод
сцены
взаимодействия
с
ресурсами на экран
Регистр
игры
состояний Запись кода текущего
состояния игры в
регистр
состояний
игры
Регистр
игры
состояний Получение
идентификатора
следующей сцены
Диаграмма прецедентов (см. рис. 1.2) приписывает прецеденты к
субъектам. Она также позволяет пользователю установить отношения между
прецедентами, конечно, если такие отношения существуют.
16
Вывод сцены выбора
действий
Вывод сцены
взаимодействия с
ресурсами
БД СКДИ
Выбор ДИ в
стартовой сцене
Выбор действия
на сцене действий
<<include>>
Вычисление
состояния игры
<<extend>>
Обращение к ресурсу на
сцене взаимодействия с
ресурсами
Игрок
Получение
идентификатора
следующей сцены
Запись кода текущего
состояния игры
Завершение
игры
Регистр состояний игры
Рисунок 1.2. Диаграмма прецедентов для операционной модели
Чтобы представить полную модель прецедентов необходимо более
подробное описание элементов диаграммы (прецедентов и субъектов).
1.4.1 Документирование прецедентов
Каждый прецедент должен быть описан с помощью документально
зафиксированного потока событий (flow of events). Соответствующий текстовый
документ определяет, что должна делать система, когда субъект инициирует
прецедент. Потоки событий для прецедентов описаны в таблицах 1.2 – 1.9:
Краткое описание
Актеры
Предусловия
Основной поток
Альтернативные
потоки
Постусловия
Краткое описание
Актеры
Предусловия
Основной
Поток
Таблица 1.2. Прецедент 1: Выбор ДИ в стартовой сцене
Прецедент дает возможность Игроку выбрать деловую игру.
Игрок.
Игрок запустил приложение.
1. Игроку выводится стартовая сцена.
2. Игрок выбрал деловую игру на сцене.
Если Игрок завершил игру, то вывести конечную сцену игры.
Игрок выбрал деловую игру.
Таблица 1.3. Прецедент 2: Выбор действия на сцене действий
Прецедент дает возможность Игроку выбрать действие на сцене выбора
действий.
Игрок.
Игрок выбрал ДИ в стартовой сцене или Игрок закончил взаимодействие с
ресурсами.
1. Вывести действия на экран.
2. Игрок выбирает действие на сцене.
17
Альтернативные
потоки
Постусловия
Краткое описание
Актеры
Предусловия
Основной
Поток
Альтернативные
потоки
Постусловия
Краткое описание
Актеры
Предусловия
Основной
Поток
Альтернативные
потоки
Постусловия
Краткое описание
Актеры
Предусловия
Основной
Поток
Альтернативные
потоки
Постусловия
Краткое описание
Актеры
Предусловия
Основной
Поток
Если в БД нет сцены с полученным кодом сцены, то Игроку выводится
сообщение об ошибке, производится переход к предыдущей сцене.
Игрок выбрал действие.
Таблица 1.4. Прецедент 3: Обращение к ресурсу (ресурсам)
в сцене взаимодействия с ресурсами
Прецедент дает возможность Игроку при необходимости выбрать ресурс
или ресурсы на сцене взаимодействия с ресурсами.
Игрок.
Осуществлён переход к сцене обращения к ресурсу (ресурсам).
1. Вывести ресурсы на экран.
2. Игрок выбирает ресурс на сцене.
Нет.
Игрок выбрал ресурс.
Таблица 1.5. Прецедент 4: Вычисление состояния игры
Текущее состояние игры определяется выбранным Игроком действием.
Для каждого действия существует своё условие перехода к следующей
сцене, которое хранится в БД СКДИ.
Игрок, БД СКДИ.
Игрок выбрал действие на сцене.
1. Получить код выбранного действия.
2. Найти в БД соответствующее идентификатору действия условие
перехода.
3. Привести условие перехода к виду двоичного кода.
Если по идентификатору выбранного действия в БД СКДИ не было
найдено условие перехода, то Игроку будет выведено сообщение об
ошибке.
Состояние игры было вычислено.
Таблица 1.6. Прецедент 5: Вывод сцены выбора действий на экран
Из БД СКДИ по идентификаторам выбираются ресурсы, соответствующие
идентификатору сцены (полученному из регистра состояний игры) и
идентификатору ранее выбранного Игроком действия, формируется сцена
выбора действий.
БД СКДИ.
Из регистра состояний игры получен идентификатор сцены, Игрок выбрал
действие (или действие было выбрано игрой автоматически, в случае если
на сцене выбора действий было только одно действие).
1. Получить код сцены.
2. По коду сцены найти сцену в БД.
3. Получить ресурсы сцены из БД.
4. Расположить ресурсы на сцене.
5. Вывести ресурсы на экран.
6. Сформировать сцену взаимодействия с ресурсами.
Если в БД не был найден код сцены, то Игроку будет выведено сообщение
об ошибке, осуществлён переход к предыдущей сцене.
Сцена выбора действий была выведена на экран.
Таблица 1.7. Прецедент 6: Вывод сцены взаимодействия с ресурсами на экран
Из
БД
СКДИ
по
идентификаторам
выбираются
действия,
соответствующие идентификатору сцены, полученному из регистра
состояний игры, формируется сцена взаимодействия с ресурсами.
БД СКДИ.
Из регистра состояний игры получен идентификатор сцены.
1. Получить код сцены.
2. По коду сцены найти сцену в БД.
18
Альтернативные
потоки
Постусловия
Краткое описание
Актеры
Предусловия
Основной
Поток
Альтернативные
потоки
Постусловия
Краткое описание
Актеры
Предусловия
Основной
Поток
Альтернативные
потоки
Постусловия
3. Получить действия сцены из БД.
4. Сформировать сцену взаимодействия с ресурсами.
Если в БД не был найден код сцены, то Игроку будет выведено сообщение
об ошибке.
На сцену было/были выведены действие/действия.
Таблица 1.8. Прецедент 7: Запись кода текущего состояния игры
в регистр состояний игры
Кодом текущего состояния игры считается приведённое к виду двоичного
кода условие перехода к следующей сцене, полученное из БД СКДИ по
идентификатору выбранного Игроком действия.
Регистр состояний игры.
Было вычислено текущее состояние игры.
1. Записать приведённая к виду двоичного кода последовательность
переходов в регистр состояний игры.
2. Изменить значение логической переменной для ОМ на false.
Если, приведённая к виду двоичного кода последовательность
переходов = null, то Игроку будет выведено сообщение об ошибке.
Код текущего состояния игры записан в регистр состояний игры.
Таблица 1.9. Прецедент 8: Получение идентификатора следующей сцены
Операционная модель получает из регистра состояний идентификатор
следующей сцены, занесённый туда автоматной моделью после перехода к
следующему оператору по строке ЛСА и преобразования оператора в
идентификатор следующей сцены игры.
Регистр состояний игры.
В регистре состояний игры было изменено значение логической
переменной для ОМ с false на true.
1. Обратиться к регистру состояний.
2. Считать идентификатор следующей сцены.
Если значение логической переменной для ОМ = false и идентификатор
следующей сцены = null, то выдать Игроку сообщение об ошибке.
Из регистра состояний игры был получен идентификатор следующей
сцены.
1.4.2 Моделирование видов деятельности
Моделирование видов деятельности необходимо для документирования
потока событий, который должна выполнять СКДИ в момент, когда субъект
инициирует прецедент. В описание видов деятельности включаются краткое
описание
прецедента,
участвующие
субъекты,
предусловия
для
начала
выполнения прецедента, описание последовательности действий в основном
потоке, альтернативный поток для определения исключительных ситуаций,
постусловия обозначающие завершение выполнения прецедента.
Описательная спецификация прецедента «Выбор ДИ в стартовой сцене»
приведена в таблице 1.10:
№
1
Таблица 1.10. Установление действий в основном и альтернативных потоках для
прецедента «Выбор ДИ в стартовой сцене»
Формулировка прецедента
Состояние вида деятельности
Игроку выводится стартовая сцена.
Вывести стартовую сцену со списком.
19
№
2
3
Формулировка прецедента
Состояние вида деятельности
Игрок выбрал деловую игру на сцене.
Выбирать ДИ из списка игр.
Если Игроку завершил игру, то будет При условии, что завершил игру: вывести
выведена конечная сцена.
конечную сцену.
Диаграмма активности для прецедента «Выбор ДИ в стартовой сцене»
изображена на рисунке 1.3:
Прецедент 1: Выбор ДИ в стартовой сцене
Игрок
Вывести стартовую сцену
со списком ДИ
[Игрок не завершил игру]
[Игрок завершил игру]
Вывести конечную
сцену
Выбирать ДИ из
списка игр
Рисунок 1.3. Диаграмма активности для прецедента «Выбор ДИ в стартовой сцене»
Описательная спецификация прецедента «Выбор действия на сцене
действий» приведена в таблице 1.11:
№
1
2
3
Таблица 1.11. Установление действий в основном и альтернативных потоках для
прецедента «Выбор действия на сцене действий»
Формулировка прецедента
Состояние вида деятельности
Вывести действия на экран.
Вывести действия на сцену.
Игрок выбирает действие на сцене.
Выбрать действие.
Если в БД нет сцены с полученным кодом При условии, что в БД нет сцены с
сцены, то Игроку выводится сообщение об полученным кодом: вывести сообщение
ошибке,
производится
переход
к об ошибке, прейти к предыдущей сцене.
предыдущей сцене.
Диаграмма активности для прецедента «Выбор действия на сцене
действий» изображена на рисунке 1.4:
20
Прецедент 2: Выбор действия на сцене действий
Игрок
[В БД найден код сцены]
[В БД не найден код сцены]
Вывести сообщение
об ошибке
Вывести действия
на сцену
Перейти к
предыдущей сцене
Выбирать действие
Рисунок 1.4. Диаграмма активности для прецедента «Выбор действия на сцене действий»
Описательная
спецификация
прецедента
«Обращение
к
ресурсу
(ресурсам) в сцене взаимодействия с ресурсами» приведена в таблице 1.12:
№
1
2
Таблица 1.12. Установление действий в основном и альтернативных потоках для
прецедента «Обращение к ресурсу (ресурсам) в сцене взаимодействия с ресурсами»
Формулировка прецедента
Состояние вида деятельности
Вывести ресурсы на экран.
Выбрать ресурс.
Игрок выбирает ресурс на сцене.
Нажать кнопку с выбранным ресурсом.
Диаграмма активности для прецедента «Обращение к ресурсу (ресурсам) в
сцене взаимодействия с ресурсами» изображена на рисунке 1.5:
Прецедент 3: Обращение к ресурсу (ресурсам) в сцене
взаимодействия с ресурсами
Игрок
Вывести ресурсы на
сцену
Выбрать ресурс
Рисунок 1.5. Диаграмма активности для прецедента «Обращение к ресурсу (ресурсам) в сцене
взаимодействия с ресурсами»
21
Описательная спецификация прецедента «Вычисление состояния игры»
приведена в таблице 1.13:
№
1
2
3
4
Таблица 1.13. Установление действий в основном и альтернативных потоках для
прецедента «Вычисление состояния игры»
Формулировка прецедента
Состояние вида деятельности
Получить
идентификатор
выбранного Получить код выбранного действия..
действия.
Найти
в
БД
соответствующее Найти в БД условие перехода.
идентификатору
действия
условие
перехода.
Привести условие перехода к виду Преобразовать условие
перехода в
двоичного кода.
двоичный код.
Если по идентификатору выбранного При условии, что по коду выбранного
действия в БД СКДИ не было найдено действия в БД СКДИ не было найдено
условие перехода, то Игроку будет условие перехода: вывести сообщение об
выведено сообщение об ошибке.
ошибке.
Диаграмма активности для прецедента «Вычисление состояния игры»
изображена на рисунке 1.6:
Прецедент 4: Вычисление состояния игры
Игрок
БД СКДИ
Получить код
выбранного действия
Найти условие
перехода
[Не найдено условие
перехода]
Вывести сообщение
об ошибке
[Найдено условие
переходов]
Преобразовать условие
перехода в двоичный код
Рисунок 1.6. Диаграмма активности для прецедента «Вычисление состояния игры»
Описательная спецификация прецедента «Вывод сцены выбора действий
на экран» приведена в таблице 1.14:
№
1
Таблица 1.14. Установление действий в основном и альтернативных потоках для
прецедента «Вывод сцены выбора действий на экран»
Формулировка прецедента
Состояние вида деятельности
Получить код сцены.
Получить код сцены.
22
№
2
3
4
5
Формулировка прецедента
Состояние вида деятельности
По коду сцены найти сцену в БД.
Найти сцену в БД.
Получить действия сцены из БД.
Получить действия.
Сформировать сцену выбора действий.
Сформировать сцену.
Если в БД не был найден код сцены, то При условии, что в БД не найден код
Игроку будет выведено сообщение об сцены: вывеси сообщение об ошибке,
ошибке,
осуществлён
переход
к перейти к предыдущей сцене.
предыдущей сцене.
Диаграмма активности для прецедента «Вывод сцены выбора действий на
экран» изображена на рисунке 1.7:
Прецедент 5: Вывод сцены выбора действий на экран
БД СКДИ
Получить код сцены
Найти сцену в БД
[Код сцены в БД не найден]
[Код сцены в БД найден]
Вывести сообщение
об ошибке
Получить действия
Перейти к
предыдущей сцене
Сформировать сцену
Рисунок 1.7. Диаграмма активности для прецедента «Вывод сцены выбора действий на экран»
Описательная спецификация прецедента «Вывод сцены взаимодействия с
ресурсами на экран» приведена в таблице 1.15:
№
1
2
3
4
5
Таблица 1.15. Установление действий в основном и альтернативных потоках для
прецедента «Вывод сцены взаимодействия с ресурсами на экран»
Формулировка прецедента
Состояние вида деятельности
Получить код сцены.
Получить код сцены.
По коду сцены найти сцену в БД.
Найти сцену в БД.
Получить ресурсы сцены из БД.
Получить ресурсы.
Сформировать сцену выбора действий.
Сформировать сцену.
Если в БД не был найден код сцены, то При условии, что в БД не найден код
23
№
Формулировка прецедента
Состояние вида деятельности
Игроку будет выведено сообщение об сцены: вывеси сообщение об ошибке,
ошибке,
осуществлён
переход
к перейти к предыдущей сцене.
предыдущей сцене.
Диаграмма активности для прецедента «Вывод сцены взаимодействия с
ресурсами на экран» изображена на рисунке 1.8:
Прецедент 6: Вывод сцены взаимодействия с ресурсами на экран
БД СКДИ
Получить код сцены
Найти сцену в БД
[Код сцены в БД не найден]
[Код сцены в БД найден]
Вывести сообщение
об ошибке
Получить ресурсы
Перейти к
предыдущей сцене
Сформировать сцену
Рисунок 1.8. Диаграмма активности для прецедента «Вывод сцены взаимодействия с ресурсами
на экран»
Описательная спецификация прецедента «Запись кода текущего состояния
игры в регистр состояний игры» приведена в таблице 1.16:
№
1
2
3
Таблица 1.16. Установление действий в основном и альтернативных потоках для
прецедента «Запись кода текущего состояния игры в регистр состояний игры»
Формулировка прецедента
Состояние вида деятельности
Записать приведённая к виду двоичного Записать последовательность переходов в
кода последовательность переходов в виде двоичного кода в регистр состояний
регистр состояний игры.
игры.
Изменить значение логической переменной Изменить
значение
логической
для ОМ на false.
переменной для ОМ на false.
Если, приведённая к виду двоичного кода Если приведённая к виду двоичного кода
24
№
Формулировка прецедента
последовательность переходов = null,
будет выведено сообщение об ошибке.
Состояние вида деятельности
то последовательность
переходов = null:
вывести сообщение об ошибке.
Диаграмма активности для прецедента «Запись кода текущего состояния
игры в регистр состояний игры» изображена на рисунке 1.9:
Прецедент 7: Запись кода текущего состояния игры в регистр
состояний игры
Регистр состояний игры
[Приведённая к виду двоичного кода
последовательность переходов = null]
[Приведённая к виду двоичного кода
последовательность переходов <> null]
Записать последовательность
переходов в виде двоичного
кода в регистр состояний игры
Вывести сообщение
об ошибке
Изменить значение
логической переменной для
ОМ на false
Рисунок 1.9. Диаграмма активности для прецедента «Запись кода текущего состояния игры в
регистр состояний игры»
Описательная спецификация прецедента «Получение идентификатора
следующей сцены» приведена в таблице 1.17:
№
1
2
3
Таблица 1.17. Установление действий в основном и альтернативных потоках для
прецедента «Получение идентификатора следующей сцены»
Формулировка прецедента
Состояние вида деятельности
Обратиться к регистру состояний.
Обратиться к регистру состояний.
Считать идентификатор следующей сцены.
Считать
идентификатор
следующей
сцены.
Если значение логической переменной для При условии, что значение логической
ОМ = false и идентификатор следующей переменной
для
ОМ = false
и
сцены = null, то выдать Игроку сообщение идентификатор следующей сцены = null:
об ошибке.
вывести сообщение об ошибке.
Диаграмма активности для прецедента «Получение идентификатора
следующей сцены» изображена на рисунке 1.10:
25
Прецедент 8: Получение идентификатора следующей сцены
Регистр состояний игры
Обратиться к регистру
состояний
[Значение логической переменной
для ОМ = false и идентификатор
следующей сцены = null]
[Значение логической переменной
для ОМ = true и идентификатор
следующей сцены <> null]
Считать идентификатор
следующей сцены
Вывести сообщение
об ошибке
Рисунок 1.10. Диаграмма активности для прецедента «Получение идентификатора
следующей сцены»
В
ходе
информационных
этапа
систем
анализа
было
проведено
для
проведения
деловых
сравнение
игр
по
аналогов
критериям,
показателям, идентификаторам. Помимо этого, к результатам анализа можно
отнести определение функциональных требований к операционной модели
СКДИ за счёт выполненного описания прецедентов и построения модели
прецедентов, а также, за счёт дальнейшего описания видов деятельности и
построения диаграмм видов деятельности по Основному и Альтернативному
потокам, полученным после построения модели прецедентов.
26
ГЛАВА 2. ПРОЕКТИРОВАНИЕ ОПЕРАЦИОННОЙ МОДЕЛИ
2.1 Проектирование базы данных
Модель данных БД представляет собой ER-модель, которая описывает на
разных уровнях (концептуальном, логическом, физическом) набор связанных
между собой сущностей, сгруппированных по функциональным областям.
К этапам разработки модели данных относятся:
1. Разработка концептуальной модели данных.
2. Создание логической модели данных.
3. Разработка физической модели данных.
2.1.1 Концептуальная модель данных
Концептуальная модель данных представляет собой набор основных
связных сущностей СКДИ. Она отражает предметную область СКДИ, в рамках
которой ведётся дальнейшее проектирование БД и служит основой для
построения логической модели данных.
Для СКДИ концептуальная модель представлена на рисунке 2.1 и состоит
из следующих сущностей:
1. BG (ДИ) – набор деловых игр или дисциплин, которые будут
предложены заказчику и выведены списком в стартовой сцене.
2. Scenes (Сцены) – представляют собой низший уровень после
проведения декомпозиции сценария, являются точками принятия
решения Игрока.
3. Actions (Действия) – сцены выбора действий содержат в себе
действия, которые являются процессами, из которых складывается
сценарий (бизнес-процесс).
4. Resources (Ресурсы) – сцены обращения к ресурсам содержит в себе
ресурс
или
набор
ресурсов,
с
которыми
необходимо
взаимодействовать для выполнения какого-либо действия.
5. Users (Пользователи) – в качестве пользователя рассматривается
любой человек, который зарегистрирован в системе СКДИ, данная
сущность включает в себя как Игроков, так и разработчиков,
27
тестировщиков и прочих людей, непосредственно нуждающихся в
доступе к автоматизированной ДИ.
6. User_roles (Роли пользователей) – данная сущность определяет
права пользователя (например, конкретный пользователь с ролью
разработчик имеет право редактировать некоторые из программных
модулей).
BG
Users
Scenes
Actions
User_roles
Resources
Рисунок 2.1. Концептуальная модель данных
2.1.2 Логическая модель данных
Логическая модель данных является уточнением концептуальной модели,
в ней определяются атрибуты сущностей, ограничения, устанавливаются связи
между сущностями.
В логической модели данных можно выделить следующие сущности:
1. BG (ДИ).
2. Users (Пользователи).
3. User_roles (Роли пользователей).
4. Scenes (Сцены).
5. Actions (Действия).
6. Resources (Ресурсы).
У деловой игры может быть множество пользователей, и множество
пользователей могут играть в одну игру, поэтому между сущностями «BG» и
«Users» установлена связь «многие-ко-многим», как показано на рисунке 2.2:
28
BG
Users
PK
играют в
id_user
зарегистрированы
PK
id_BG
id_scene
BG_name
LSA_filepath
user_name
e-mail
Рисунок 2.2. Связь между сущностями Пользователи и ДИ
Пользователю
может
присваиваться
множество
ролей
(например,
разработчик может заходить в систему с ролью Игрок, для предварительного
тестирования сделанных им доработок). Одна роль может быть присвоена
нескольким пользователям (например, в системе зарегистрировано несколько
игроков или разработчиков), поэтому между сущностями «Users» и «User_roles»
установлена связь «многие-ко-многим», как показано на рисунке 2.3:
User_roles
Users
PK
принадлежит PK id_role
id_user
user_name
e-mail
присваивается
role_name
editor
Рисунок 2.3. Связь между сущностями Пользователи и Роли пользователей
Одна ДИ состоит из множества Сцен, но одна Сцена не может
использоваться в нескольких играх. Однократное использование Сцены вызвано
тем, что для разных ДИ в зависимости от Сцены будет подтягиваться из БД
СКДИ разный набор ресурсов и действий. Таким образом, между сущностями
«BG» и «Scenes» установлена связь «один-ко-многим», как показано на
рисунке 2.4:
Scenes
BG
PK
принадлежат
id_BG
состоит из PK id_scene
operation_name
id_scene
BG_name
LSA_filepath
Рисунок 2.4. Связь между сущностями ДИ и Сцены
В одну сцену можно вывести несколько действий для реализации ТПР
Игрока. Действие, которое уже было разработано может использоваться
неоднократно в разных сценах, следовательно, между сущностями «Scenes» и
«Actions» должна быть установлена связь «многие-ко-многим», как показано на
рисунке 2.5:
29
Actions
Scenes
PK
принадлежит PK id_action
id_scene
состоит из
term
operation_name
Рисунок 2.5. Связь между сущностями Сцены и Действия
Аналогично для ресурсов, сцена состоит из нескольких ресурсов для
реализации ТПР Игрока. Ресурс, который уже был разработан, может
использоваться
неоднократно
в
разных
сценах,
следовательно,
между
сущностями «Scenes» и «Resources» должна быть установлена связь «многие-комногим», как показано на рисунке 2.6:
Resources
Scenes
PK
принадлежит
id_scene
состоит из
PK
id_resource
resource_name
filepath
operation_name
Рисунок 2.6. Связь между сущностями Сцены и Ресурсы
Результатом построения таблиц для сущностей БД СКДИ и установления
между ними связей является общая схема логической модели данных, которая
представлена на рисунке 2.7:
BG
Users
PK
id_user
играют в
зарегистрированы
PK
id_BG
id_scene
BG_name
LSA_filepath
user_name
e-mail
состоит
из
присваивается
принадлежит
принадлежит
User_roles
PK
id_role
Scenes
PK
role_name
editor
состоит
из
id_scene
operation_name
состоит из
принадлежит
Resources
PK
id_resource
resource_name
filepath
Рисунок 2.7. Логическая модель данных
30
Actions
принадлежит
PK
id_action
term
2.1.3 Физическая модель данных
Схема
данных
представляет
собой
детализированный
вариант
концептуальной модели данных с описанием полей для конкретных таблиц,
созданием вспомогательных таблиц, установлением силы связей между
таблицами.
Таблица «BG» представляет собой описание сущности Деловая игра. В
таблице 2.1 приводится описание полей таблицы:
Поле
id_BG
BG_name
LSA_filepath
Тип значения
numeric(18, 0)
nchar(100)
nchar(600)
Допускаются
пустые
значения
Нет
Нет
Нет
Таблица 2.1. Таблица «BG»
Примечание
Идентификатор ДИ
Название ДИ
Путь к файлу со строкой ЛСА
Таблица «BG_users» является вспомогательной таблицей и служит для
обеспечения связи многие-ко-многим между сущностями ДИ и Пользователь. В
таблице 2.2 приводится описание полей таблицы:
Поле
Id
id_BG
id_user
Тип значения
numeric(18, 0)
numeric(18, 0)
numeric(18, 0)
Допускаются
пустые
значения
Нет
Нет
Нет
Таблица 2.2. Таблица «BG_users»
Примечание
Идентификатор
Идентификатор ДИ
Идентификатор сцены
Таблица «Users» представляет собой описание сущности Пользователь. В
данной таблице хранится информация обо всех зарегистрированных в системе
пользователях и сотрудниках, взаимодействующих с СКДИ. В таблице 2.3
приводится описание полей таблицы:
Поле
id_user
user_name
e-mail
Таблица
Тип значения
numeric(18, 0)
nchar(100)
nchar(100)
«Roles»
Допускаются
пустые
значения
Нет
Нет
Да
представляет
собой
Таблица 2.3. Таблица «Users»
Примечание
Идентификатор пользователя
ФИО пользователя
Электронный адрес пользователя
описание
сущности
Роль
пользователя. В данной таблице хранится информация о ролях пользователей
СКДИ. В таблице 2.4 приводится описание полей таблицы:
31
Поле
Тип значения
Допускаются
пустые
значения
Нет
id_role
numeric(18, 0)
role_name
Editor
nchar(10)
Bit
Нет
Нет
reg_date
Date
Да
Таблица 2.4. Таблица «Roles»
Примечание
Идентификатор
роли
пользователя
Роль пользователя
Признак того, что пользователь с
данной ролью обладает правом
на редактирование программных
модулей
Дата регистрации в СКДИ
Таблица «Game_scenes» представляет собой описание сущности Сцена. В
данной таблице хранится информация о сценах СКДИ. В таблице 2.5 приводится
описание полей таблицы:
Поле
Тип значения
id_scene
id_action
id_resource
operation_name
numeric(18, 0)
numeric(18, 0)
numeric(18, 0)
nchar(10)
id_BG
numeric(18, 0)
Таблица 2.5. Таблица «Game_scenes»
Допускаются
Примечание
пустые
значения
Нет
Идентификатор сцены
Нет
Идентификатор действия
Да
Идентификатор ресурса
Нет
Наименование
прецедента
(операции)
Нет
Идентификатор ДИ
Таблица «Scenes_actions» является вспомогательной таблицей и служит
для обеспечения связи многие-ко-многим между сущностями Сцена и Действие.
В таблице 2.6 приводится описание полей таблицы:
Поле
Id
id_scene
id_action
Тип значения
numeric(18, 0)
numeric(18, 0)
numeric(18, 0)
Таблица 2.6. Таблица «Scenes_actions»
Допускаются
Примечание
пустые
значения
Нет
Идентификатор
Нет
Идентификатор сцены
Нет
Идентификатор действия
Таблица «Actions» представляет собой описание сущности Действие. В
данной таблице хранится информация о действиях СКДИ. В таблице 2.7
приводится описание полей таблицы:
Поле
id_action
Term
Тип значения
numeric(18, 0)
nchar(100)
Допускаются
пустые
значения
Нет
Нет
32
Таблица 2.7. Таблица «Actions»
Примечание
Идентификатор действия
Условие перехода для действия
Таблица «Scenes_resources» является вспомогательной таблицей и служит
для обеспечения связи многие-ко-многим между сущностями Сцена и Ресурс. В
таблице 2.8 приводится описание полей таблицы:
Поле
Id
id_scene
id_resource
Тип значения
numeric(18, 0)
numeric(18, 0)
numeric(18, 0)
Таблица 2.8. Таблица «Scenes_resources»
Допускаются
Примечание
пустые
значения
Нет
Идентификатор
Нет
Идентификатор сцены
Нет
Идентификатор ресурса
Таблица «Resources» представляет собой описание сущности Ресурсы. В
данной таблице хранится информация о ресурсах, которые используются при
формировании сцен СКДИ. В таблице 2.9 приводится описание полей таблицы:
Поле
id_resource
resource_name
Filepath
Тип значения
numeric(18, 0)
nchar(10)
nchar(300)
Допускаются
пустые
значения
Нет
Да
Нет
Таблица 2.9. Таблица «Resources»
Примечание
Идентификатор ресурса
Наименование ресурса
Путь к файлу, в котором
расположен ресурс
Таблица «Users_roles» является вспомогательной таблицей и служит для
обеспечения связи многие-ко-многим между сущностями Пользователи и Роли
пользователей. В таблице 2.10 приводится описание полей таблицы:
Поле
Id
id_user
id_role
Тип значения
numeric(18, 0)
numeric(18, 0)
numeric(18, 0)
Таблица 2.10. Таблица «Users_roles»
Допускаются
Примечание
пустые
значения
Нет
Идентификатор
Нет
Идентификатор пользователя
Нет
Идентификатор
роли
пользователя
Для проектирования и построения схемы данных БД СКДИ были
использованы логическая и концептуальная модели данных, описание которых
приведено выше.
Для проектирования таблиц была использована физическая модель
данных. Более подробная физическая схема данных представлена на рисунке 2.8.
Физическая схема данных включает в себя сущности - BG, Game scenes, Users,
User roles, Actions, Resources:
33
Рисунок 2.8. Физическая модель данных
2.2 Проектирование макетов форм
На этапе проектирования был разработан макет для экранной формы,
который строился для определённой сцены игры и представлял собой точку
принятия решения. На экран Игроку выводились все действия для сцены и
ресурсы, необходимые для этих действий (см. рис. 2.9):
Модель сцены
Действия сцены:
Ресурсы игры:
Действие1
Ресурс1
Ресурс2
Ресурс3
Ресурс4
Действие2
Ресурс5
Ресурс6
Ресурс7
Ресурс8
Действие3
Ресурс9
Ресурс10
Ресурс11
Ресурс12
...
...
Рисунок 2.9. Макет формы для отображения игровой сцены
34
Несмотря на то, что в макете формы отображена вся необходимая Игроку
информация о сцене, было решено разделить форму для отображения сцены на
две: форма для выбора действия и форма для взаимодействия с ресурсами, так
как точка принятия решения может содержать множество действий и множество
игровых ресурсов. Помимо избавления от нагромождённости формы кнопками с
действиями и ресурсами, разбиение формы сцены на две позволит обеспечить
логику
прохождения
теоретическим
игры
материалом,
–
сначала
Игрок
содержащимся
в
должен
форме
ознакомиться
с
взаимодействия
с
ресурсами, а затем приступить к практической части (выбору действия в
текущей игровой ситуации). Сцена состоит из ресурсов и действий, которые
попадая в операционную модель, обрабатываются с помощью механизма
расположения объектов на форме, в результате чего определяются их
координаты (см. рис. 2.10)
Операции
(действия)
Механизм
расположения
объектов на
форме
Сцена
Игровые
ресурсы
Форма выбора
действия
Форма
взаимодействия
с ресурсами
Операционная
модель
Рисунок 2.10. Схема построения форма операционной модели
На последней стадии этапа проектирования макетов были разработаны
следующие макеты форм:
1. Стартовая форма (см. рис. 2.11) – представляет собой панель с
возможностью выбора ДИ, список ДИ для формы должен
выбираться из базы данных (при наличии в базе данных более чем
12 деловых игр на форме появляются кнопки со стрелками для
просмотра страниц с ДИ, которые не поместились на одной
странице).
35
СКДИ
Выберите Деловую игру из списка:
ДИ1
ДИ2
ДИ3
ДИ4
ДИ5
ДИ6
ДИ7
ДИ8
ДИ9
ДИ10
ДИ11
ДИ12
Рисунок 2.11. Макет стартовой сцены
2. Форма выбора действия (см. рис. 2.12) – на форме автоматически
генерируются кнопки с действиями, которые можно совершить в
текущей схеме.
СКДИ
В игре произошла ситуация «Описание ситуации, произошедшей в
ДИ выбранной Игроком» Что в такой ситуации следует
предпринять на следующем шаге?
Действие 1
Действие 2
Действие 3
Рисунок 2.12. Макет сцены выбора действия
36
3. Форма взаимодействия с ресурсами (см. рис. 2.13) – необходима для
обеспечения
теоретического
блока
выбранной
дисциплины
(деловой игры).
СКДИ
Выберите инструменты для выбранного Вами действия
«Действие N»
Управление
Входы
Выходы
Механизмы
Рисунок 2.13. Макет сцены взаимодействия с ресурсами
4. Конечная сцена (см. рис. 2.14) – выводится Игроку после того, как
записанная автоматной моделью в регистр состояний сцена равна
«К», что означает достижение конца строки ЛСА или завершение
прохождения материала по выбранной Игроком дисциплине.
СКДИ
Игра окончена
Вы набрали ___ баллов
Ваш текущий уровень компетенций «___________»
Рисунок 2.14. Макет конечной сцены
37
На этапе проектирования были разработаны концептуальная, логическая и
физическая модели данных для подсистемы проведения деловых игр, после чего
с помощью SQL Management Studio спроектированная база данных была
наполнена
данными.
В
ходе
проектирования
было
решено
провести
декомпозицию формы для сцены на форму выбора действия и форму
взаимодействия с ресурсами. Далее, с помощью Microsoft Visio 2010 были
разработаны макеты диалоговых форм для прототипа Студии компетентностных
деловых игр.
38
ГЛАВА 3. РАЗРАБОТКА ОПЕРАЦИОННОЙ МОДЕЛИ
3.1 Средства, использованные для осуществления интеграции
операционной и автоматной моделей
Для
разработки
прототипа
СКДИ
использовалось
следующее
программное обеспечение:
1. Microsoft Visual Studio 2010 – для построения экранных форм было
разработано на объектно-ориентированном языке C# приложение
Windows Form Application.
2. SQL Server Management Studio – использовалось на этапе
проектирования базы данных прототипа СКДИ.
Интеграция операционной и автоматной моделей произведена за счёт
регистра состояний игры, который содержит всю необходимую информацию для
моделей во время проведения деловой игры. Регистр состояний игры
представляет собой строковый массив, к которому можно обращаться из любой
формы приложения. Элементами массива являются:
1. Register.Arr[0] – идентификатор ДИ.
2. Register.Arr[1] – идентификатор текущей сцены.
3. Register.Arr[2] – код, выбранного Игроком действия в виде
двоичного кода.
4. Register.Arr[3] – активная на текущий момент модель (если
действующая модель операционная, то в регистр состояний игры
записывается строка – «О», если действующая модель автоматная,
то в регистр состояний игры записывается строка - «А»).
3.2 Алгоритм проведения игры для подсистемы проведения
Алгоритм проведения игры начинается с момента выбора Игроком
деловой игры. Взаимодействие между операционной и автоматной моделями
ведётся через регистр состояний игры, куда записывается вся необходимая
информация о текущем состоянии игры. В связи с тем, что диалог Игрока с
игрой реализуется операционной моделью, после того как Игрок выбрал ДИ в
стартовой форме, операционная модель записывает в регистр состояний игры
идентификатор ДИ из базы данных и активизирует автоматную модель.
39
Хранение идентификатора ДИ необходимо автоматной модели для того, чтобы
выбрать соответствующую ДИ логическую схему алгоритма на следующем шаге
алгоритма.
После выбора логической схемы алгоритма для деловой игры, выбранной
Игроком, автоматная модель начинает проверку ЛСА на корректность. Если
найдена ошибка, то в игровом режиме запуска приложения пользователю будет
выведено сообщение об ошибке, при запуске приложения в режиме отладки,
пользователь
исправляет
ошибки,
допущенные
в
ЛСА
и
записывает
исправленную ЛСА в файл. После подтверждения, что выбранная ЛСА записана
без ошибок, АМ начинает разбор ЛСА.
Так как разбор ЛСА автоматной моделью является циклическим и
продолжается до тех пор, пока ЛСА не пройдена до конца, необходима проверка
кода текущей сцены в ЛСА. Если значение кода сцены, записанное в регистр
состояний игры на предыдущем этапе, является пустым, то разбор ЛСА ещё не
начат. В таком случае, автоматная модель считывает первую сцену из ЛСА и
записывает её в регистр состояний игры. Значение кода сцены, записанное в
регистр состояний игры на предыдущем этапе, равно «К», если игра пройдена до
конца. После того как игра пройдена операционной моделью осуществляется
вывод на экран конечной формы, в которой Игрок оповещается о том, что игра
закончена. Если код сцены, записанный в регистр состояний игры на
предыдущем этапе, не равен пустому значению или «К», то автоматная модель
считывает из регистра состояний игры бинарный код действия Игрока
выбранного на предыдущем этапе. В соответствии со значением бинарного кода
АМ осуществляет переход к следующей сцене игры. Если считанная сцена не
является конечной, то код сцены записывается в регистр состояний игры. Для
того
чтобы
завершить
работу
автоматной
модели
она
должна
быть
деактивирована, после чего в регистр состояний игры записывается информация
о том, что ОМ активна. Более подробное описание алгоритма работы автоматной
модели приведено на рисунке 3.1.
40
Начало
AM активна?
+
Код предыдущей
cцены в
регистре = Null
-
+
Считать ЛСА из
БД
Проверить
корректна ли ЛСА
Совершить переход по ЛСА
по полученному из регистра
коду действия
-
ОМ выполняет свою работу
Двоичный код
действия в
регистре = null
+
Деактивировать
ОМ
-
Записать в регистр
код тек. сцены
+
Игрок завершил игру
Деактивировать
АМ
Вывести
конечную сцену
Активировать
ОМ
Активировать
АМ
Конец
Рисунок 3.1. Алгоритм работы автоматной модели
После активации ОМ происходит считывание из регистра состояний игры
кода сцены, которая должна быть выведена Игроку на экран. В игре
предусмотрены стартовая и конечная формы, формы выбора действия, формы
взаимодействия с ресурсами. Если сцена является конечной, то игроку
выводится форма о завершении игры, иначе по коду сцены операционная модель
считывает из базы данных все действия, которые можно совершить Игроку в
полученной сцене, и игровые ресурсы, которые могут содержать в себе
теоретический материал для выполнения выбранных действий. Первоначально
строится форма взаимодействия с ресурсами, в которой Игрок может
ознакомиться с предложенным ему материалом, либо перейти непосредственно
к выполнению задания. После взаимодействия с ресурсами строится сцена для
выбора действия в текущей сцене. Игрок выбирает действие, код которого
преобразуется операционной моделью в двоичный код и записывается в регистр
состояний игры. После того, как в регистре появляется информация о том, какое
действие было выбрано Игроком (в регистр записан двоичный код действия для
перехода по ЛСА к следующей сцене), операционная модель становится
41
неактивной, происходит активация автоматной модели. Более подробное
описание алгоритма работы операционной модели приведено на рисунке 3.2.
Начало
ОМ активна?
+
Получить код сцены из ЛСА
-
+
Сцена является
конечной?
Считать из регистра код
текущей сцены
Вывести
конечную сцену
Считать из БД ресурсы
текущей сцены
Сформировать сцену
взаимодействия ресурсов
Конец
Считать из БД действия
текущей сцены
Сформировать сцену выбора
действия
-
+
Выбрано не менее 1 действия
Записать в регистр пустую
строку как код действия
Сформировать и записать в регистр
двоичный код выбранного действия
Деактивировать ОМ
Активировать АМ
Рисунок 3.2. Алгоритм работы операционной модели
Процесс прохода по ЛСА автоматной моделью и построения форм для
каждой из сцен операционной моделью является циклическим. Для ОМ при
однократном прохождении по циклу реализуется построение сцены с
теоретической и практической точки зрения (форма взаимодействия с
ресурсами, форма выбора действия в сложившейся игровой ситуации). Для АМ
при однократном прохождении по циклу реализуется переход по полученному
из регистра состояний условию перехода от ОМ по строке ЛСА к следующей
сцене в игре.
42
3.3 Разработка форм игры
Макеты форм, разработанные на этапе проектирования, дорабатывались и
изменялись на этапе разработки.
На рисунке 3.3 представлена стартовая сцена для прототипа СКДИ. Для
формы реализован механизм автоматической генерации кнопок с ДИ,
необходимый в связи с тем, что количество ДИ, хранящихся в базе данных,
может постоянно дополняться. Для создания кнопок и их размещения на форме
был разработан механизм, реализованный в процедуре CreateButtons:
//countBg - количество кнопок на форме
//myArrList - список названий кнопок
private void CreateButtons(int countBG, ArrayList myArrList)
{
int height = panel1.Size.Height;
int width = panel1.Size.Width;
int locUpDown = 25;
int locLeftRight = 0;
int i = 0;
foreach (Object objReader in myArrList)
{
string btnName = objReader.ToString();
Button btn = new Button();
btn.Name = btnName;
btn.Size = new Size(150, 60);
if (i % 4 == 0 && i!=0)
{
locUpDown = locUpDown + 85;
locLeftRight = 150;
}
else
{ locLeftRight = locLeftRight + 150; }
btn.Location = new Point(locLeftRight, locUpDown);
btn.Text = objReader.ToString();
btn.UseVisualStyleBackColor = true;
btn.Click += new EventHandler(btn_Click);
Controls.Add(btn);
btn.BackColor = Color.FromName("GradientInactiveCaption");
btn.Text = btn.Text.Trim();
btn.Enabled = true;
i++;
if
(btn.Location.X
>
panel1.Location.X
||
btn.Location.Y
panel1.Location.Y)
{
panel1.AutoScroll = true;
if
(panel1.AutoScrollMargin.Width
<
5
panel1.AutoScrollMargin.Height < 5)
{
panel1.SetAutoScrollMargin(5, 5);
}
}
panel1.Controls.Add(btn);
}
}
>
||
В процедуру CreateButtons передаются параметры countBg, myArrList,
которые задаются в процедуре SelectFromDB - из базы данных с помощью
43
SQL-запроса выбирается список необходимых для построения форы названий
кнопок (ДИ, ресурсы, действия) и определяется количество выбранных
названий.
Рисунок 3.3. Стартовая сцена
На рисунке 3.4 представлена сцена взаимодействия с игровыми ресурсами
СКДИ. Разделение на блоки управление, входы, выходы, механизмы было
исключено из формы, так как было решено перенести механизм, связанный с
вычислением штрафа из подсистемы проведения в подсистему мониторинга. На
форму выводятся только ресурсы с типом управление (предназначенные только
для чтения), то есть нередактируемые пользователем. В качестве таких ресурсов
в игре могут использоваться файлы различных форматов, например, jpg, pdf, doc,
и тому подобные.
Рисунок 3.4. Сцена взаимодействия с ресурсами
44
При нажатии на кнопку с ресурсом происходит открытие файла, в котором
хранится теоретический материал для выполнения задания. Если пользователь
уверен в своих знаниях, то он может сразу перейти к выполнению задания,
нажав на кнопку «Перейти к выполнению задания». Для работы с ресурсами для
каждой сгенерированную кнопку создаётся событие btn_Click, в котором
осуществляется поиск пути к файлу ресурса с помощью SQL-запроса к БД и
программно описывается открытие файла.
На рисунке 3.5 представлена сцена выбора действия. На форме также
задействован механизм автоматической генерации кнопок. При открытии формы
Игрок видит набор возможных действий и описание сцены.
Рисунок 3.5. Сцена выбора действия
После того как Игрок выбирает действие, его код должен быть
преобразован к виду двоичного кода. Получение кода действие реализовано за
счёт SQL-запроса. Оно описывается в событии, срабатывающим после нажатия
на кнопку с выбранным действием:
SqlConnection
con
=
new
SqlConnection("Data
Catalog=CBGS;Integrated Security=True");
con.Open();
SqlCommand com = new SqlCommand("select distinct A.term "
+ "from Actions A "
+ "where A.name = @name", con);
com.Parameters.Add("@name", System.Data.SqlDbType.VarChar);
com.Parameters["@name"].Value = btnName;
btnName = Convert.ToString(com.ExecuteScalar()); con.Close();
45
Source=KATE-ПК;Initial
В случае если должен производиться безусловный переход по строке ЛСА
на форму будет выведено название сцены «Безусловный переход», Игрок
должен будет нажать кнопку «Далее».
Если на сцене есть кнопки для выбора действий (не безусловный переход
по строке ЛСА), то должно быть реализовано преобразование полученного из
SQL-запроса кода действия к виду двоичного кода:
public string BinaryAction(string Act)
{
string Binary;
if (Act == "")
{
Binary = "";
return Binary;
}
else{
Act.Trim();
Act.ToUpper();
Binary = "";
char[] mass = Act.ToCharArray();
for (int i = 0; i < Act.Length - 1; i++)
{
if (mass[i] == 'P' && i - 1 >= 0)
{
if (mass[i - 1] == '!')
Binary = Binary + "0";
else
Binary = Binary + "1";
}
else if (mass[i] == 'P' && i == 0)
Binary = Binary + "1";
else if (mass[i] == ' ')
break;
}
return Binary;
}
}
Если переход по строке ЛСА был безусловным, то в регистр состояний
игры будет записана пустая строка, в противном случае двоичный код. После
того, как в форме выбора действий в регистр состояний был записан двоичный
код действия, происходит деактивация ОМ и активация АМ.
3.4 Контрольный пример
Для
контрольного
примера
была
выбрана
строка
ЛСА
«H0a1p1u1d3p2u2a2p3u3d2a3d1a4k». В ЛСА описаны четыре сцены: a1 –
«Сцена 1», a2 – «Сцена 2», a3 – «Безусловная сцена 1», a4 – «Безусловная сцена
2». Безусловная сцена не предполагает наличия формы выбора действий.
В начале игры выбирается ДИ, в качестве ДИ была выбрана игра
«Прототип» (см. рис. 3.3). После выбора игры осуществляется переход по ЛСА к
46
первой сцене - a1, для неё строится
форма взаимодействия с игровыми
ресурсами, на которую из базы выводятся все ресурсы данной сцены. На
рисунке 3.6 показано что произойдёт, если Игрок выберет «Ресурс С», путь к
файлу которого «E:\схема БД СКДИ ласт.jpg». В базе данных прописывается
путь к файлу с ресурсом, после выбора ресурса производится открытие файла с
указанным в базе путём к файлу.
Рисунок 3.6. Выбора ресурса «Ресурс С» на форме взаимодействия с ресурсами
Если Игрок не хочет изучать теоретический материал, представленный на
форме взаимодействия с ресурсами, или он уже ознакомился со всеми
необходимыми ресурсами, он должен нажать кнопку «Перейти к выполнению
задания». После перехода к выполнению задания, Игрок видит форму выбора
действия для сцены «а1» (см. рис. 3.7).
Если Игрок выбирает «Действие 1.2», код условия перехода по ЛСА для
которого в базе данных записывается как «P1P2», АМ осуществляет переход к
сцене «а2» или «Сцена 2». Далее Игроку выводится форма для взаимодействия с
ресурсами сцены «Сцена 2», предположим, что на этот раз Игрок уже ранее
ознакомился с игровыми ресурсами и сразу перешёл к выполнению задания в
сцене «а2» нажав на кнопку «Перейти к выполнению задания». На сцене
«Сцена 2» Игроку выводится набор действий для текущей сцены, который
включает в себя «Действие 2.1» и «Действие 2.2».
47
Рисунок 3.7. Выбора действия «Действие 1.2» на форме выбора действия в сцене «а1»
Игрок выбирает «Действие 2.1» (см. рис. 3.8), в базе данных код этого
действия закодирован как «P3», по строке ЛСА осуществляется переход к сцене
«а3» или «Безусловная сцена 1» (см. рис. 3.9).
Рисунок 3.8. Выбора действия «Действие 2.1» на форме выбора действия в сцене «а2»
Для всех сцен игры предполагается наличие формы взаимодействия с
ресурсами, в том числе данная форма предусмотрена для безусловных сцен.
Безусловные сцены можно найти в строке ЛСА по отсутствию для них условий
перехода, которые обозначаются в ЛСА как: «pn», где n – это целое число
48
(номер условия). Для выбранной ЛСА сценами с безусловными переходами
будут «а3» и «а4». Безусловные сцены выводятся на экран с целью отображения
перехода по ЛСА, Игрок в них нажимает на кнопку «Далее» и переходит к
следующим сценам в соответствии со сценарием, прописанным в ЛСА.
Рисунок 3.9. Переход к безусловной сцене «а3»
После того как была пройдена сцена «а3», игра заканчивается и Игроку
выводится конечная сцена. В конечной сцене Игрок может вернуться к
стартовой сцене со списком всех деловых игр, нажав на кнопку со стрелкой. При
наведении на кнопку перехода к стартовой сцене
появляется всплывающая
подсказка «Перейти к выбору ДИ» (см. рис. 3.10):
Рисунок 3.10. Конечная сцена
49
Прежде чем приступить к этапу разработки для понимания того, как
должна происходить интеграция моделей, был описан алгоритм работы
операционной и автоматной моделей.
На этапе разработки в Visual Studio 2010 было разработано приложение
WindowsForm, отвечающее за выполнение функций операционной модели.
Далее, с помощью регистра состояний игры была проведена интеграция ОМ и
АМ.
50
ЗАКЛЮЧЕНИЕ
Результатом выполнения выпускной квалификационной работы является
выполнение поставленных задач. В работе было проведено сравнение аналогов
СКДИ по показателям, критериям, индикаторам, для сравнения были выбраны
два аналога СКДИ: SimulTrain и SimVenture. Для того чтобы определить
функциональные требования к операционной модели, была построена модель
прецедентов операционной модели с их подробным описанием. По описанным
основному и альтернативному потокам в модели прецедентов было проведено
описание видов деятельности и построены диаграммы активности (видов
деятельности).
На объектно-ориентированном языке C# было разработано приложение,
реализующее функции ОМ, а также произведена интеграция ОМ и АМ (что в
конечном итоге является подсистемой проведения ДИ). Приложение позволяет
Игроку работать в двух режимах – игровом и отладочном. Для ОМ СКДИ было
разработано частное техническое задание (см. прил. C), а также руководство
пользователя (см. прил. D). Кроме того, были спроектированы концептуальная,
логическая и физическая (схема БД СКДИ) модели данных. Спроектированная
БД была наполнена данными. Для Студии компетентностных деловых игр был
написан
бизнес-план,
включающий
в
себя
экономическое
разработки студии, которое приводится в приложении B.
51
обоснование
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Левин М. Как технологии изменяют образование: пять главных трендов //
[Электронный ресурс]
FORBES
[Режим
доступа:
http://m.forbes.ru/article.php?id=82871] [Проверено: 30.04.2014].
2. Управление знаниями: Учеб. пособие / Под ред. Л.А. Трофимова,
В.В. Трофимовой. СПб.: СПбГУЭФ, 2012. – 77 с.
3. Intelligent systems for aerospace engineering – an overview [Текст]: NASA
Technical Report: 42-44 / NASA Ames Research Center; исполн.:
Krishnakumar K. – United States, 2003. – 15 c. – Библиогр.: с. 15.
4. R. A. Wells Management Games and Simulations in Management Development:
An Introduction // Journal of Management Development. 1990. Vol. 9, Issue 2.
p.4-6.
5. Deryabin A., Shestakova L., Vikentyeva O. The construction of competencybased business game operational model // International Journal «Information
Technologies & Knowledge». 2013. Vol. 7, Number 4. p. 3-13.
6. Глушков В.М., Трахтенброт Б.А. Введение в теорию конечных автоматов.
М.: СП ЭКОМ, 1962. 384 с.
7. Словарь
современной
экономической
науки
[Текст]:
экономико-
математический словарь / Л.И. Лопатников. – 5-е изд., перераб. и доп. –
М.: Дело, 2003. – 520 с.
8. Ляпунов А.А. О математических проблемах кибернетики // Известия
высших учебных заведений. Казань: Математика. – 1958. – № 5. – с.166174.
9. Olding E. “Engagification” of the Enterprise – Gamification and Employee
Engagement
//
Gartner
[Электронный ресурс]
[Режим
доступа:
http://blogs.gartner.com/elise-olding/2012/11/14/engagificationof-theenterprise-gamification-and-employee-engagement/] [Проверено: 30.04.2014].
52
Мультиязычность
Расширяемость команд
Бесплатные демо-версии
Есть ли срок лицензии
Наличие скидок
Управляющие
Операционные
Поддерживающие
Наличие встроенного механизма оценивания
Ранжирование игроков
Бонусы за лидерство
Для ВУЗов
Корпоративный
Для физических лиц
СКДИ
+
+
+
+
+
+
+
+
+
+
+
+
+
+
SimVenture
+
+
+
+
+
+
+
+
+
Simultrain
+
+
+
+
+
+
+
+
+
+
+
+
Адаптивность игры к результатам игрока
Предупреждение об ошибках
ДИ
Интуитивно понятный интерфейс
Показатели
53
Тип доступа к
игре
Рейтинг
игрока
Встроенные
БП
Стоимости
лицензий
Команды
управляющей
модели
Диалог с
пользователем
Критерии
ПРИЛОЖЕНИЕ A. СРАВНЕНИЕ АВТОМАТИЗИРОВАННЫХ
ДЕЛОВЫХ ИГР
Таблица А.1. Критерии, Индикаторы, Показатели для обзора аналогов СКДИ
Индикаторы
ПРИЛОЖЕНИЕ B. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ
Расчет финансовых затрат
Финансовый
план
составлен
на
перспективу
2
лет
с
момента
первоначальных вложений в проект. Методика оценки, используемая в расчетах,
соответствует принципам бюджетного подхода. В соответствии с принципами
бюджетного
подхода,
каждый
из
временных
интервалов
(интервалы
планирования) рассматривается с точки зрения притоков и оттоков денежных
средств. На основании потоков денежных средств определяются основные
показатели эффективности и финансовой состоятельности проекта.
Расчеты выполнены в рублях, в постоянных ценах, принимаемых на
момент формирования бизнес-плана (2 квартал 2014 года) и соответствующего
налогового окружения.
Налоговое окружение проекта
Упрощённая система налогообложения — 13%.
Общие инвестиции
Инвестиционные
вложения
в
проект
составляют
298 626
рублей
(см. табл. B.1) и направлены на оформление и закупку оборудования для ООО
«КДИ»:
Наименование
Сервер
Телефон
Шлюз Grandstream GXW4004
Межсетевой экран Cisco PIX 501
Столы
Стулья
Итого:
Таблица B.1. Инвестиционные расходы
Цена
Кол-во
Стоимость
250 000,00
1
250 000,00
250,00
5
1 250,00
6 400,00
1
6 400,00
17 476,00
1
17 476,00
3 000,00
5
15 000,00
1 700,00
5
8 500,00
298 626,00
Доходы проекта
Доходы проекта складываться из количества заключённых сделок на
разработку дисциплины умноженной на стоимости разработки одной
дисциплины в рассматриваемом месяце. Собственные вложения в УК
компании
составляют
по
30 000
54
рублей
с
каждого
учредителя,
следовательно,
собственные
вложения
в
УК
=
30 000*3=90 000.
Прогнозируемая выручка представлена в таблице B.2.
Таблица B.2. Планируемая выручка
1 год существования фирмы
2014
Наименование услуги
1
2
3
4
Выручка
15000 15000 15000 15000
Кол-во оказанных услуг
1
1
1
1
Цена услуги, руб
15000 15000 15000 15000
2014
Наименование услуги
7
8
9
10
Выручка
30000 40000 40000 40000
Кол-во оказанных услуг
2
2
2
2
Цена услуги, руб
15000 20000 20000 20000
2 год существования фирмы
2015
Наименование услуги
13
14
15
16
Выручка
60000 60000 60000 60000
Кол-во оказанных услуг
3
3
3
3
Цена услуги, руб
20000 20000 20000 20000
2015
Наименование услуги
19
20
21
23
Выручка
80000 80000 80000 80000
Кол-во оказанных услуг
4
4
4
4
Цена услуги, руб
20000 20000 20000 20000
5
6
15000 15000
1
1
15000 15000
2015
11
12
40000 40000
2
2
20000 20000
17
18
60000 80000
3
4
20000 20000
2016
24
25
80000 80000
4
4
20000 20000
Расходная часть
Инвестиционные расходы приведены в таблице B.3. Общехозяйственные
расходы представлены в таблице B.4.
Таблица B.3. Инвестиционные расходы
Наименование
Цена
250 000,00
250,00
6 400,00
17 476,00
3 000,00
1 700,00
Сервер
Телефон
Шлюз Grandstream GXW4004
Межсетевой экран Cisco PIX 501
Столы
Стулья
Кол-во
1
5
1
1
5
5
Итого:
Стоимость
250 000,00
1 250,00
6 400,00
17 476,00
15 000,00
8 500,00
298 626,00
Таблица B.4. Общехозяйственные расходы
Наименование
Аренда
з/п с отчислениями
Амортизация
Текущие расходы
Услуги связи
Итого:
Стоимость
15 000,00
152 490,00
0,00
500,00
2 000,00
169 990,00
55
Расходы на Фонд оплаты труда (ФОТ) персонала составляют 152 490
рублей в месяц (см. табл. B.5) при среднесписочной численности 6 человек, с
учётом того, что руководитель одновременно является разработчиком и его з/п
учитывается только как з/п разработчика.
Таблица B.5. ФОТ
Числен
-ность
Налоги
(30%)
З/п
Проектировщи
к БП
Разработчик
20 000,00
20 000,00
1
2
20 000,00
40 000,00
23000
46000
29 900,00
59 800,00
12 000,00
1
12 000,00
13800
17 940,00
15 000,00
2
6
30 000,00
34500
44 850,00
152490,00
Бухгалтерия
Менеджер
Производств.
Производств.
АУП и
вспом.
АУП и
вспом.
Итого:
ФОТ
Уральский
коэффициент
(15%)
Наименование Персонал
Ставка дисконтирования вычислялась по следующим формулам:
𝑑 = 𝐸𝑚𝑖𝑛 + 𝐼 + 𝑟,
(B.1)
где d – номинальная ставка дисконтирования, 𝐸𝑚𝑖𝑛 – минимальная реальная
ставка дисконтирования (тридцатилетние гособлигации США на момент
времени), I – темп инфляции, r -
коэффициент, учитывающий уровень
инфляционного риска.
Для вычисления r (премии за риск) используется следующая формула:
𝑟 = 𝑟страновой + 𝑟надёжности участника проекта
(B.2)
+ 𝑟неполученных предусмотренных доходов
Чтобы перейти от номинальной ставки дисконтирования к реальной
используется следующая формула:
𝑖годовая =
1+𝑑
− 1,
1+𝜋
(B.3)
где 𝜋 – уровень инфляции, d – номинальная ставка дисконтирования.
Так как в качестве одного периода берётся месяц, в расчётах должна
использоваться реальная месячная ставка дисконтирования, которая находится
по формуле:
12
𝑖месячная = √(1 + 𝑖годовая ) + 1
56
(B.4)
Результаты вычислений приведены в таблице B.6:
Таблица B.6 . Вычисление ставки дисконтирования
0,0874
Премия за страновой риск России, rстрановой
0,0130
Премия а риск надёжности участника, rстрановой
Премия
за
риск
неполученных
непредусмотренных
доходов, 0,500
rнеполученных предусмотренных доходов
Премия за риск, r
0,1504
Номинальная ставка дисконтирования, d
0,8114
0,1321
Переход от номинальной ставки дисконтирования к реальной ставке. iгодовая
2,0104
Реальная месячная ставка дисконтирования, iмесячная
Отчёт о движении денежных средств за 2 года представлен в таблице B.7:
Таблица B.7. Отчёт о движении денежных средств
1 год существования фирмы
2014
Наименование показателя мар
апр
май
июн
июл
авг
Выручка, R
15000 15000 15000 15000 15000 15000
Себестоимость, C
10000 10000 10000 10000 10000 11000
EBIT
5000 5000
5000
5000
5000
4000
Налоговые отчисления
650
650
650
650
650
520
Чистая прибыль
4350 4350
4350
4350
4350
3480
2014
2015
Наименование показателя сент
окт
ноя
дек
янв
фев
Выручка, R
30000 40000 40000 40000 40000 40000
Себестоимость, C
15000 15000 15000 15000 15000 15000
EBIT
15000 25000 25000 25000 25000 25000
Налоговые отчисления
1950 3250
3250
3250
3250
3250
Чистая прибыль
13050 21750 21750 21750 21750 21750
2 год существования фирмы
2015
Наименование показателя мар
апр
май
июн
июл
авг
Выручка, R
60000 60000 60000 60000 60000 80000
Себестоимость, C
32000 32000 32000 32500 32500 32500
EBIT
28000 28000 28000 27500 27500 47500
Налоговые отчисления
3640 3640
3640 3575
3575
6175
Чистая прибыль
24360 24360 24360 23925 23925 41325
2015
2016
Наименование показателя сент
окт
ноя
дек
янв
фев
Выручка, R
80000 80000 80000 80000 80000 80000
Себестоимость, C
36000 36000 36350 37200 37350 37350
EBIT
44000 44000 43650 42800 42650 42650
Налоговые отчисления
5720 5720 5674,5 5564 5544,5 5544,5
Чистая прибыль
38280 38280 37976 37236 37106 37106
Расчёт показателей экономической прибыли приведён в таблице B.8. Как
видно из таблицы, проект окупается на восьмой месяц, если считать началом
запуска проекта март 2014 года, то в октябре 2014 года получаемая прибыль
перестанет быть отрицательной и составит 22 974,00 рублей.
57
Таблица B.8. Показатели экономической эффективности
№
периода
Инвестиции,
I
1
2
3
4
5
6
7
8
9
10
11
12
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
№
периода
13
14
15
16
17
18
19
20
21
22
23
24
Итого:
Инвестиции,
I
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
298 626,00
2 371 800,00
1 год существования фирмы
Прибыль,
Коэффициент
Pr
дисконтирования, d
15 000,00
2,01
15 000,00
2,01
15 000,00
2,01
15 000,00
2,01
15 000,00
2,01
15 000,00
2,01
30 000,00
2,01
40 000,00
2,01
40 000,00
2,01
40 000,00
2,01
40 000,00
2,01
40 000,00
2,01
2 год существования фирмы
Прибыль,
Коэффициент
Pr
дисконтирования, d
60 000,00
2,01
60 000,00
2,01
60 000,00
2,01
60 000,00
2,01
60 000,00
2,01
80 000,00
2,01
80 000,00
2,01
80 000,00
2,01
80 000,00
2,01
80 000,00
2,01
80 000,00
2,01
80 000,00
2,01
58
PV=Pr*d
NPV=∑PV –
I
30 150,00
30 150,00
30 150,00
30 150,00
30 150,00
30 150,00
60 300,00
80 400,00
80 400,00
80 400,00
80 400,00
80 400,00
-268 476,00
-238 326,00
-208 176,00
-178 026,00
-147 876,00
-117 726,00
-57 426,00
22 974,00
103 374,00
183 774,00
264 174,00
344 574,00
PV=Pr*d
120 600,00
120 600,00
120 600,00
120 600,00
120 600,00
160 800,00
160 800,00
160 800,00
160 800,00
160 800,00
160 800,00
160 800,00
NPV=∑PV –
I
465 174,00
585 774,00
706 374,00
826 974,00
947 574,00
1 108 374,00
1 269 174,00
1 429 974,00
1 590 774,00
1 751 574,00
1 912 374,00
2 073 174,00
ПРИЛОЖЕНИЕ C. ТЕХНИЧЕСКОЕ ЗАДАНИЕ
НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ВЫСШАЯ
ШКОЛА ЭКОНОМИКИ
(НИУ
ВШЭ)
УТВЕРЖДАЮ
Подпись и дата
СОГЛАСОВАНО
к.т.н., доцент кафедры
к.т.н., доцент кафедры
информационных технологий в
информационных технологий в
бизнесе
бизнесе
_____________ О.Л. Викентьева
_____________ О.Л. Викентьева
“___”________________ 2014 г.
“___”________________ 2014 г.
ОМ.СКДИ.01.ТЗ.01
КОМПЕТЕНТНОСТНЫХ ДЕЛОВЫХ ИГР (ОМ СКДИ)
Представители
Техническое задание
на разработку
предприятия-разработчика
Взам. инв. №
СОГЛАСОВАНО
к.т.н., доцент кафедры
информационных технологий в
бизнес-информатики
бизнесе
НИУ ВШЭ-Пермь
Подпись и дата
Инв. № дубл.
Листов 19
ОПЕРАЦИОННАЯ МОДЕЛЬ СТУДИИ
_____________ О.Л. Викентьева
_____________ Е.А. Голева
“___”________________ 2014 г.
“___”________________ 2014 г.
Студентка 4 курса факультета
ЛИСТ УТВЕРЖДЕНИЯ
Руководитель разработки
к.т.н., доцент кафедры
Инв.№ подп.
информационных технологий в
бизнесе
_____________ О.Л. Викентьева
“___”________________ 2014 г.
Исполнитель
Студентка 4 курса факультета
бизнес-информатики
НИУ ВШЭ-Пермь
_____________ Е.А. Голева
“___”________________ 2014 г.
2014
59
УТВЕРЖДЁН
ОПЕРАЦИОННАЯ МОДЕЛЬ СТУДИИ
КОМПЕТЕНТНОСТНЫХ ДЕЛОВЫХ ИГР (ОМ СКДИ)
Техническое задание на разработку
Техническое задание на разработку
ОМ.СКДИ.01.ТЗ.01
Листов 19
Инв.№ подп.
Подпись и дата
Взам. инв. №
Инв. № дубл.
Подпись и дата
ОМ.СКДИ.01.ТЗ.01
2014
60
Настоящее техническое задание (ТЗ) на разработку ОМ СКДИ разработано
согласно
ГОСТ 19.201-78 и содержит требования по реализации в ОМ СКДИ экранных форм
игры (сцен), а также процессов формирования сцен, выбора действий и ресурсов в
сцене, чтения и редактирования ресурсов игры и вычисления текущего состояния игры.
61
СОДЕРЖАНИЕ
1
Введение ........................................................................................................................... 64
1.1 Наименование программы и условное обозначение .................................................... 64
1.2 Краткая характеристика области проведения программы .......................................... 64
2
Основание для разработки ОМ СКДИ .......................................................................... 64
2.1 Основание для проведения разработки ......................................................................... 64
2.2 Наименования организаций Исполнителя и Заказчика ............................................... 64
2.3 Шифр разработки ............................................................................................................ 64
3
Назначение разработки ................................................................................................... 64
3.1 Функциональное назначение.......................................................................................... 64
3.2 Эксплуатационное назначение ....................................................................................... 65
4
Требования к программе ................................................................................................. 65
4.1 Требования к функциональным характеристикам ....................................................... 65
4.1.1 Требования к составу выполняемых функций ......................................................... 65
4.1.2 Требования к организации входных данных ........................................................... 65
4.1.3 Требования к организации выходных данных ......................................................... 66
4.1.4 Требования к временным характеристикам ............................................................. 66
4.2 Требования к надёжности ............................................................................................... 66
4.2.1 Требования к обеспечению устойчивого функционирования программы ........... 66
4.2.2 Время восстановления после отказа ......................................................................... 67
4.2.3 Отказы из-за некорректных действий оператора (Игрока) .................................... 67
4.3 Условия эксплуатации .................................................................................................... 67
4.3.1 Климатические условия эксплуатации ..................................................................... 67
4.3.2 Требования к видам обслуживания .......................................................................... 67
4.3.3 Требования к численности и квалификации персонала .......................................... 67
4.3.4 Требования к конечному пользователю программного продукта ......................... 68
4.4 Требования к составу и параметрам технических средств ......................................... 68
4.4.1 Требования к программному обеспечению.............................................................. 68
4.4.2 Поддерживаемые архитектуры ................................................................................. 68
4.4.3 Требования к оборудованию для установки ............................................................ 68
4.5 Требования к информационной и программной совместимости ............................... 69
4.5.1 Требования к информационным структурам и методам решения ......................... 69
4.5.2 Требования к исходным кодам и языкам программирования ................................ 69
4.5.3 Требования к программным средствам, используемым программой ................... 69
4.5.4 Требования к защите информации программ .......................................................... 69
62
4.6 Требования к маркировке и упаковке ........................................................................... 69
4.6.1 Требования к маркировке .......................................................................................... 69
4.6.2 Требования к упаковке ............................................................................................... 70
4.7 Требования к транспортированию и хранению............................................................ 71
4.7.1 Условия транспортировки и хранения ..................................................................... 71
4.8 Специальные требования................................................................................................ 71
5
Требования к программной документации ................................................................... 71
5.1 Предварительный состав программной документации ............................................... 71
5.2 Специальные требования к программной документации ........................................... 71
6
Технико-экономические показатели.............................................................................. 71
6.1 Ориентировочная экономическая эффективность ....................................................... 71
6.2 Предполагаемая годовая потребность ........................................................................... 71
6.3 Экономические преимущества разработки ................................................................... 71
7
Стадии и этапы разработки ............................................................................................ 71
7.1 Стадии разработки........................................................................................................... 71
7.2 Этапы разработки ............................................................................................................ 72
7.3 Содержание работ по этапам.......................................................................................... 72
7.4 Исполнители .................................................................................................................... 74
8
Порядок контроля и приёмки ......................................................................................... 74
8.1 Виды испытаний .............................................................................................................. 74
8.2 Общие требования к приёмке работы ........................................................................... 75
Перечень сокращений ............................................................................................................ 76
63
1. ВВЕДЕНИЕ
1.1.
Наименование программы и условное обозначение
1.1.1 Полное наименование — «Операционная
модель
Студии
Компетентностных Деловых Игр».
1.1.2 Версия системы — 1.0.
1.1.3 Краткое наименование — ОМ СКДИ.
1.2. Краткая характеристика области проведения программы
Программа предназначена к применению на автоматизируемых рабочих
местах НИУ ВШЭ.
2. ОСНОВАНИЕ ДЛЯ РАЗРАЗОТКИ ОМ СКДИ
2.1.
Основание для проведения разработки
Основанием для проведения работ по разработке ОМ СКДИ является
документ от 01.09.2013 «Задание на выполнение выпускной квалификационной
работы бакалавра».
2.2.
Наименования организаций Исполнителя и Заказчика
2.2.1 Заказчиком на разработку ОМ СКДИ (Заказчик) является Факультет
бизнес-информатики НИУ ВШЭ-Пермь, представителем заказчика является
Викентьева Ольга Леонидовна, к.т.н., доцент кафедры информационных
технологий в бизнесе – 614000, г. Пермь, ул. Бульвар Гагарина, 37а.
2.2.2 Разработчиком ОМ СКДИ (Исполнитель) является студентка 4
курса факультета бизнес-информатики НИУ ВШЭ-Пермь, Голева Екатерина
Анатольевна – 614000, г. Пермь, ул. Карпинского, 101.
2.3.
3.1.
Шифр разработки
Условное обозначение (шифр) темы разработки — «ОМ.СКДИ».
3. НАЗНАЧЕНИЕ РАЗРАБОТКИ
Функциональное назначение
Операционная модель Студии Компетентностных Деловых Игр является
частью Подсистемы Проведения ДИ и служит для выполнения следующего
набора функций:
 Формирование базовых экранных форм игры (сцен игры) и их вывод на
экран Игроку;
 Обеспечение взаимодействия Игрока с действиями сцен;
 Обеспечение взаимодействия Игрока с ресурсами сцен;
 Реализация диалога с Игроком с помощью всплывающих подсказок;
64
 Вычисление текущего состояния игры после выбора на сцене действия
или ресурса (ресурсов).
3.2.
Эксплуатационное назначение
Программа должна эксплуатироваться в профильных подразделениях на
объектах Заказчика. Конечными пользователями программного продукта
должны являться студенты НИУ ВШЭ или сотрудники подразделений объектов
Заказчика.
При создании ОМ СКДИ должны быть решены следующие задачи:
 Наполнение формы действиями и ресурсами из БД СКДИ;
 Возможность чтения ресурсов, относящихся к группам: входы,
управление, механизмы;
 Возможность редактирования ресурсов, относящихся к группе выходы;
 Формирование строкового массива для Регистра состояний игры и его
заполнение операционной и автоматной моделями в ходе проведения
игры;
 Приведение
выбранной
последовательности
переходов,
которая
определяется после выбора действия Игроком, к виду двоичного кода;
 Запись преобразованной к виду двоичного кода последовательности
переходов в Регистр состояний игры.
4. ТРЕБОВАНИЯ К ПРОГРАММЕ
4.1.
Требования к функциональным характеристикам
4.1.1. Требования к составу выполняемых функций
Программа
должна
обеспечивать
возможность
выполнения
перечисленных ниже функций:
 Функция выбора ДИ;
 Функция выбора действия;
 Функция выбора ресурса;
 Функция чтения ресурса;
 Функция редактирования ресурса;
 Функция вызова механизма;
 Функция ведения диалога с пользователем в форме всплывающих
подсказок.
4.1.2. Требования к организации входных данных
Входные данные для ОМ формируются АМ и записываются в регистр
состояний игры. Входные данные должны быть организованы в виде
65
идентификаторов сцен, действий и ресурсов БД СКДИ. Для вывода ресурсов, в
таблицу БД СКДИ с ресурсами для каждого идентификатора прописывается
путь к соответствующему файлу.
Файлы должны храниться на локальных носителях.
4.1.3. Требования к организации выходных данных
Выходные данные записываются в регистр состояний игры и включают в
себя:
 признак активации АМ;
 условие перехода, записанное в виде двоичного кода;
 изменённый Игроком файл (ресурс).
Выходные данные, передаваемые в АМ, записываются в строковый
массив, состоящий из следующих элементов:
 условие переходов, записанная двоичным кодом – тип данных string,
при записи кода осуществляется посимвольная проверка строки
(допустимые символы 1 и 0);
 признак активации АМ – тип данных string, после того, как ОМ
завершает обработку выполненных Игроком действий, в данный
элемент массива записывается «АМ», в свою очередь ОМ начинает
свою работу после того, как в регистре состояний значение данного
элемента массива меняется на «ОМ».
Выходные данные, которые представляют собой ресурсы, с которыми
взаимодействовал Игрок (была задействована функция записи в файл)
записываются на локальный носитель (путь к файлу, в котором будет сохранён
файл прописан в таблице ресурсов БД СКДИ).
4.1.4. Требования к временным характеристикам
Завершение игры производится автоматически при условии, что Игрок
остаётся на экранной форме более трёх часов.
4.2.
Требования к надёжности
4.2.1. Требования
к
обеспечению
устойчивого
функционирования
программы
Надёжное (устойчивое) функционирование программы должно быть
обеспечено
выполнением
Заказчиком
совокупности
организационно-
технических мероприятий, список которых приведён ниже:
 использование лицензионного ПО;
 организация бесперебойного питания технических средств;
66
 регулярным
выполнением
требований
ГОСТ
51188-98.
Защита
информации.
 испытания программных средств на наличие компьютерных вирусов.
Типовое руководство.
4.2.2. Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем электропитания
технических средств (иными внешними факторами), не фатальны сбоем (не
крахом) ОС, не должно превышать времени, необходимого на перезагрузку ОС
и запуск программы, при условии соблюдения условий эксплуатации
технических программных средств.
Время
восстановления
после
отказа,
вызванного
неисправностью
технических средств, фатальным сбоем (крахом) ОС, не должно превышать
времени, требуемого на устранение неисправностей технических средств и
переустановки программных средств.
4.2.3. Отказы из-за некорректных действий оператора (Игрока)
Отказы программы возможны вследствие некорректных действий
оператора (Игрока) при взаимодействии с ОС. Во избежание возникновения
отказов программы по указанной выше причине следует обеспечить работу
конечного пользователя без предоставления ему административных привилегий.
4.3.
Условия эксплуатации
4.3.1. Климатические условия эксплуатации
Климатические
условия
эксплуатации,
при
которых
должны
обеспечиваться заданные характеристики, должны удовлетворять требованиям,
предъявляемым к техническим средствам в части условий их эксплуатации.
4.3.2. Требования к видам обслуживания
Программа не требует проведения каких-либо видов обслуживания.
4.3.3. Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы ОМ СКДИ,
должно составлять не менее одной штатной единицы – разработчик.
Разработчик должен являться студентом 4 курса факультета бизнесинформатики НИУ ВШЭ. В перечень задач разработчика входит:
 предварительный анализ и проектирование сцен игры;
 разработка ОМ СКДИ;
 интеграция ОМ с АМ СКДИ;
67
 задача установки (инсталляции) и поддержания работоспособности
системных программных средств ОС;
 задача установки (инсталляции) программного продукта на стороне
Заказчика.
4.3.4. Требования к конечному пользователю программного продукта
Персонал должен быть аттестован на II квалификационную группу по
электробезопасности (для работы с ПК).
4.4.
Требования к составу и параметрам технических средств
В состав технических средств Заказчика должен входить ПК с
установленным ПО – Microsoft Visual Studio 2010, Microsoft SQL Server 2008 R2.
4.4.1. Требования к программному обеспечению
Microsoft Visual Studio 2010 можно установить в следующих ОС:
 Windows XP (x86) с пакетом обновления 3 (SP3) — все выпуски кроме
Starter;
 Windows Vista (x86 и x64) с пакетом обновления 1 (SP1) — все выпуски
кроме Starter;
 Windows 7 (x86 и x64);
 Windows Server 2003 (x86 и x64) с пакетом обновления 2 (SP2);
 Windows Server 2003 R2 (x86 и x64);
 Windows Server 2008 (x86 и x64) с пакетом обновления 2 (SP2);
 Windows Server 2008 R2 (x64).
32–разрядная версия Microsoft SQL Server 2008 R2 можно установить в
следующих ОС:
 Windows Server 2003 SP2;
 Windows Server 2008 SP2;
 Windows 2008 R2 64-bit.
4.4.2. Поддерживаемые архитектуры
 32-разрядная (x86);
 64-разрядная (x64).
4.4.3. Требования к оборудованию для установки
Для Microsoft Visual Studio 2010:
 процессор с частотой 1,6 ГГц или выше;
 1024 МБ ОЗУ;
 3 ГБ свободного места на диске;
68
 жесткий диск со скоростью 5400 оборотов в минуту;
 видеоадаптер с поддержкой DirectX 9 и разрешением 1280 x 1024 (или
более высоким);
 дисковод DVD-ROM.
Для SQL Server 2008 R2:
 процессор с частотой 1,0 ГГц или выше;
 1 ГБ ОЗУ.
4.5.
Требования к информационной и программной совместимости
4.5.1. Требования к информационным структурам и методам решения
Информационная структура с файлами изображений, которые будут
использоваться для отображения кнопок и фона экранной формы (сцены),
должна включать в себя изображения предусмотренные спецификацией формата
jpg.
Информационная структура файлов (ресурсов) предназначенных для
форм взаимодействия Игрока с ресурсами должна включать в себя файлы
форматов doc, xls, pdf, jpg, png, mp3.
4.5.2. Требования к исходным кодам и языкам программирования
Исходные коды программы должны быть реализованы на объектноориентированном языке программирования C#.
4.5.3. Требования к программным средствам, используемым программой
Системные программные средства, используемые программой, должны
быть представлены лицензионной локализованной версией ОС.
4.5.4. Требования к защите информации программ
Требования к защите информации и программ не предъявляются.
4.6.
Требования к маркировке и упаковке
Программа поставляется в виде программного
изделия
-
на
дистрибутивном (внешнем оптическом) носителе (компакт-диске).
4.6.1. Требования к маркировке
Программный продукт должен обладать маркировкой с обозначением
товарного
знака
компании-Исполнителя,
наименования,
номера
версии,
порядкового номера, даты изготовления и номера сертификата соответствия
Госстандарта России (если таковой имеется).
Маркировка наносится на программный продукт в виде наклейки,
выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.
69
4.6.2. Требования к упаковке
Упаковка программного продукта осуществляется в упаковочную тару
компании-Исполнителя.
4.6.2.1. Условия упаковывания
Упаковка программного изделия должна проводиться в закрытых
вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и
относительной влажности не более 80 % при отсутствии агрессивных примесей
в окружающей среде.
4.6.2.2. Порядок упаковки
Подготовленный к упаковке программный продукт укладывают в тару,
представляющую собой коробку из картона гофрированного (ГОСТ 7376-89 или
ГОСТ 7933-89) согласно чертежам предприятия-изготовителя тары.
Программный продукт
упаковывается с применением чехлов из
водонепроницаемой пленки с обязательным наличием химически неагрессивных
влагопоглотителей (силикагеля).
Для
заполнения
свободного
пространства
в
упаковочную
тару
укладываются прокладки из гофрированного картона или пенопласта.
Эксплуатационная
документация
должна
содержаться
внутри
потребительской тары вместе с программным продуктом.
На
верхний
слой
прокладочного
материала
укладывается
товаросопроводительная документация - упаковочный лист и ведомость
упаковки.
Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ
18251-87.
Упакованные в потребительскую тару программные продукты должны
быть уложены на поддон, стянуты лентой для предотвращения потери формы
груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания
влаги.
В коробку поддона должна быть вложена товаросопроводительная
документация, в том числе упаковочный лист согласно ГОСТ 25565-88.
Габариты грузового места должны быть не более 1250 x 820 x 1180 мм.
Масса НЕТТО - не более 200 кг.
Масса БРУТТО - не более 220 кг.
70
4.7.
Требования к транспортированию и хранению
4.7.1. Условия транспортировки и хранения
Допускается транспортирование программного продукта в транспортной
таре всеми видами транспорта (в том числе в отапливаемых герметизированных
отсеках
самолетов
без
ограничения
расстояний).
При
перевозке
в
железнодорожных вагонах вид отправки - мелкий малотоннажный.
При транспортировании и хранении программного продукта должна быть
предусмотрена защита от попадания пыли и атмосферных осадков. Не
допускается
кантование программного изделия. Климатические
условия
транспортирование приведены ниже:
 температура окружающего воздуха: (20±5) °С;
 атмосферное давление: от 84 до 105 кПа (630-800 мм рт.ст.);
 относительная влажность воздуха: (60±20) %.
4.8.
5.1.
Специальные требования
Специальные требования к программному продукту не предъявляются.
5. Требования к программной документации
Предварительный состав программной документации
Состав программной документации должен включать в себя:
 техническое задание;
 программу и методики испытаний;
 руководство пользователя;
 ведомость эксплуатационных документов.
5.2.
Специальные требования к программной документации
Специальные
требования
к
программной
документации
не
предъявляются.
6.1.
6.2.
6. Технико-экономические показатели
Ориентировочная экономическая эффективность
Ориентировочная экономическая эффективность не рассчитывается.
Предполагаемая годовая потребность
Предполагаемое число использований программы в год – 250 сеансов
работы на одном рабочем месте.
6.3.
7.1.
Экономические преимущества разработки
Экономические преимущества разработки не рассчитываются.
7. Стадии и этапы разработки
Стадии разработки
Разработка программного продукта включает в себя следующие стадии
разработки:
71
 формирование требований Заказчика;
 проектирование ОМ;
 разработка программного модуля для ОМ;
 тестирование программного модуля для ОМ.
7.2.
Этапы разработки
На стадии формирования требований Заказчика должны быть выполнены
следующие этапы разработки:
 разработка требований к функционалу ОМ Исполнителем;
 согласование требований, предъявляемых к ОМ, с Заказчиком;
 утверждение требований Исполнителем и Заказчиком.
На стадии проектирования ОМ должны быть выполнены следующие
этапы разработки:
 исследование предметной области;
 построение модели анализа;
 построение моделей данных;
 разработка проектной документации.
На стадии разработки программного модуля для ОМ должны быть
выполнены следующие этапы разработки:
 разработка программного модуля для ОМ;
 проектирование БД СКДИ.
На стадии тестирования программного модуля для ОМ должны быть
выполнены следующие этапы разработки:
 составлен набор тестов для ОМ;
 проведено тестирование ОМ.
7.3.
Содержание работ по этапам
На этапе разработки требований к функционалу ОМ Исполнителем
должен быть выполнен приведённый ниже список работ:
 интервьюирование заказчика;
 описание функций системы;
 построение программного прототипа с использованием JAD-метода;
 составление шаблонов экранных форм.
На этапе согласования требований, предъявляемых к ОМ, с Заказчиком
должен быть выполнен приведённый ниже список работ:
 проверка обоснованности требований к функционалу ОМ;
72
 обсуждение и модифицирование не устроивших Заказчика требований;
 избавление от излишнего функционала.
На этапе утверждения требований Исполнителем и Заказчиком должен
быть выполнен приведённый ниже список работ:
 проверка составленных документов;
 подписание составленных документов.
На этапе исследования предметной области должен быть выполнен
приведённый ниже список работ:
 составлен
список
потенциальных
конкурентов,
предоставляющих
схожие услуги;
 для каждого конкурента описаны критерии, индикаторы, показатели;
 документ с согласованными ранее функциями дополнен функциями,
найденными у конкурентов, и отправлен на согласование Заказчику.
На
этапе
построения
модели
анализа
должен
быть
выполнен
должен
быть
выполнен
приведённый ниже список работ:
 построена модель прецедентов;
 построена модель видов деятельности.
На
этапе
построения
моделей
данных
приведённый ниже список работ:
 построена концептуальная модель данных;
 построена логическая модель данных;
 построена физическая модель данных.
На этапе разработки проектной документации должно быть разработано
техническое задание.
На этапе разработки программного модуля для ОМ должен быть
выполнен приведённый ниже список работ:
 организована связь БД с проектом;
 разработаны классы объектов;
 разработаны структуры данных;
 разработаны процедуры и функции.
На этапе проектирования БД СКДИ ОМ должен быть выполнен
приведённый ниже список работ:
 созданы таблицы;
 заданы типы данных полей таблиц;
73
 заданы связи между сущностями.
На этапе составления набора тестов для ОМ должен быть выполнен
приведённый ниже список работ:
 Составлены тесты для тестирования функций ОМ с помощью критериев
«Чёрного ящика»;
 Составлены тесты для тестирования функций ОМ с помощью критериев
«Минимального грубого тестирования» («Белого ящика»).
На этапе проведения тестирования ОМ должен быть выполнен
приведённый ниже список работ:
 документирование с помощью критериев «Чёрного ящика» входных
данных, ожидаемого и реального результатов, признаков соответствия
ожидаемого результата реальному результату при выполнении функций
ОМ;
 документирование с помощью критериев «Минимального грубого
тестирования» проверяемых условий для каждого из составленных
тестов.
7.4.
Исполнители
Руководитель разработки
Научный руководитель
Викентьева О.Л.
Исполнитель
Студентка 4 курса факультета БИ, НИУ Голева Е.А
ВШЭ
8.1.
8. Порядок контроля и приёмки
Виды испытаний
Приемо-сдаточные испытания должны проводиться на объекте Заказчика
в сроки с 28.04.2014 по 05.05.2014.
Приемо-сдаточные испытания программы должны проводиться согласно
разработанной
(не позднее 30.04.2014) Исполнителем и
согласованной
Заказчиком «Программы и методик испытаний».
Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель
документируют в Протоколе проведения испытаний.
74
8.2.
Общие требования к приёмке работы
После проведения испытаний в полном объёме, на основании «Протокола
проведения испытаний» Исполнитель и Заказчик утверждают «Свидетельство о
приёмке» и производят запись в программном документе «Формуляр».
75
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ
СКДИ
-
Студия компетентностных деловых игр
ОМ
-
Операционная модель
АМ
-
Автоматная модель
ОА
-
Операционный автомат
УА
-
Управляющий автомат
ДИ
-
Деловая игра
КДИ
-
Кометентностная деловая игра
ЛСА
-
Логическая схема алгоритма
БД
-
База данных
ИС
-
Информационная система
ИТ
-
Информационные технологии
НИУ ВШЭ
-
Национальный исследовательский университет Высшая школа
экономики
Кафедра ИТБ
-
Кафедра информационных технологий в бизнесе
БИ
-
Бизнес-информатика
ПО
-
Программное обеспечение
ПК
-
Персональный компьютер
МБ
-
Мегабайт
ГБ
-
Гигабайт
ОЗУ
-
Оперативное запоминающее устройство
ГГц
-
Гигагерц
SP
-
Service Pack
ОС
-
Операционная система
Кг
-
Килограмм
Мм
-
Миллиметр
ГОСТ
-
Государственный стандарт
РД
-
Руководящий документ
JAD
-
Joint Application Development
76
НИУ ВШЭ, Факультет бизнес-информатики, Кафедра ИТБ
СОСТАВИЛИ
Должность исполнителя
Фамилия, имя,
Подпись
Дата
Подпись
Дата
отчество
Студентка 4 курса факультета
Голева Е.А.
бизнес-информатики, НИУ
ВШЭ-Пермь
СОГЛАСОВАНО
Должность согласующего лица
Фамилия, имя,
отчество
к.т.н., доцент кафедры
Викентьева О.Л.
информационных технологий в
бизнесе
77
ПРИЛОЖЕНИЕ D. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
КОМПЕТЕНТНОСТНЫЕ ДЕЛОВЫЕ ИГРЫ
УТВЕРЖДАЮ
Руководитель (разработчик, Компетнтностные деловые игры)
______________ Голева Е.А.
Печать
Дата
УТВЕРЖДАЮ
Руководитель (научный руководитель, НИУ ВШЭ)
______________ Викентьева О.Л.
Печать
Дата
ОПЕРАЦИОННАЯ МОДЕЛЬ СТУДИИ
КОМПЕТЕНТНОСТНЫХ ДЕЛОВЫХ ИГР
Руководство пользователя
ВЕРСИЯ 1
На 15 листах
Действует с «___»________2014 г.
СОГЛАСОВАНО
Руководитель (научный руководитель, НИУ ВШЭ)
______________ Викентьева О.Л.
Печать
Дата
Пермь 2014
78
СОДЕРЖАНИЕ
1. Введение ................................................................................................................... 81
1.1 Область применения ............................................................................................. 81
1.2 Краткое описание возможностей ......................................................................... 81
1.3 Уровень подготовки пользователя ...................................................................... 81
1.4 Перечень эксплуатационной документации ....................................................... 81
2. Назначение и условия применения ....................................................................... 82
2.1 Виды деятельности, функции ............................................................................... 82
2.2 Программные и аппаратные требования к системе ........................................... 82
3. Подготовка к работе ................................................................................................ 84
3.1 Состав дистрибутива ............................................................................................. 84
3.2 Запуск системы ...................................................................................................... 84
3.3 Проверка работоспособности системы ............................................................... 84
4. Описание операций ................................................................................................. 85
4.1 Операция «Выбор ДИ» ......................................................................................... 85
4.1.1 Условия выполнения операции «Выбор ДИ» .................................................. 85
4.1.2 Подготовительные действия ............................................................................. 85
4.1.3 Основные действия ............................................................................................ 85
4.1.4 Заключительные действия ................................................................................. 85
4.1.5 Ресурсы, расходуемые на операцию «Выбор ДИ» ......................................... 85
4.2 Операция «Взаимодействие с ресурсом» ............................................................ 85
4.2.1 Условия выполнения операции «Взаимодействие с ресурсом» .................... 85
4.2.2 Подготовительные действия ............................................................................. 85
4.2.3 Основные действия ............................................................................................ 85
4.2.4 Заключительные действия ................................................................................. 86
4.2.5 Ресурсы, расходуемые на операцию «Взаимодействие с ресурсом» ............ 86
4.3 Операция «Выбор действия» ................................................................................ 86
4.3.1 Условия выполнения операции «Выбор действия» ........................................ 86
4.3.2 Подготовительные действия ............................................................................. 86
4.3.3 Основные действия ............................................................................................ 86
4.3.4 Заключительные действия ................................................................................. 86
79
4.3.5 Ресурсы, расходуемые на операцию «Выбор действия» ................................ 86
4.4 Операция «Возвращение к списку ДИ» .............................................................. 86
4.4.1 Условия выполнения операции «Возвращение к списку ДИ» ...................... 86
4.4.2 Подготовительные действия ............................................................................. 87
4.4.3 Основные действия ............................................................................................ 87
4.4.4 Заключительные действия ................................................................................. 87
4.4.5 Ресурсы, расходуемые на операцию «Возвращение к списку ДИ» .............. 87
5. Аварийные ситуации .............................................................................................. 88
6. Рекомендации по освоению ................................................................................... 89
6.1 Контрольный пример ............................................................................................ 89
80
1. ВВЕДЕНИЕ
1.1. Область применения
Студию компетентностных деловых игр предполагается использовать для
развития компетенций сотрудников коммерческих организаций, а также студентов
высших учебных заведений. Процесс обретения компетенций реализован в игровой
форме.
1.2. Краткое описание возможностей
Программный модуль «Операционная модель Студии компетентностных
деловых игр» предназначен для формирования базовых экранных формы игры
(сцены игры) и их вывода на экран Игроку, обеспечение взаимодействия Игрока с
действиями сцен, обеспечение взаимодействия Игрока с ресурсами сцен, ведение
диалога с Игроком с помощью всплывающих подсказок, вычисление текущего
состояния игры после выбора на сцене действия или ресурса (ресурсов).
1.3. Уровень подготовки пользователя
Пользователь ОМ СКДИ должен иметь опыт работы с WinForms
приложениями Microsoft Visual Studio 2010.
1.4. Перечень эксплуатационной документации
Операционная модель Студии компетентностных деловых игр (ОМ СКДИ).
Техническое задание на разработку.
2. НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
2.1. Виды деятельности, функции
ОМ СКДИ обеспечивает возможность выполнения перечисленных ниже
функций:
1. Наполнение формы действиями и ресурсами из БД СКДИ.
2. Возможность чтения ресурсов, относящихся к группе управление.
3. Формирование строкового массива для Регистра состояний игры и его
заполнение операционной и автоматной моделями в ходе проведения
игры.
4. Приведение
выбранной
последовательности
переходов,
которая
определяется после выбора действия Игроком, к виду двоичного кода.
5. Запись преобразованной к виду двоичного кода последовательности
переходов в Регистр состояний игры.
2.2. Программные и аппаратные требования к системе
Требования к составу и параметрам технических средств:
В
состав
технических
средств
Заказчика
должен
входить
ПК
с
установленным ПО – Microsoft Visual Studio 2010, Microsoft SQL Server 2008 R2.
Требования к программному обеспечению:
Microsoft Visual Studio 2010 можно установить в следующих ОС:
 Windows XP (x86) с пакетом обновления 3 (SP3) — все выпуски
кроме Starter;
 Windows Vista (x86 и x64) с пакетом обновления 1 (SP1) — все
выпуски кроме Starter;
 Windows 7 (x86 и x64);
 Windows Server 2003 (x86 и x64) с пакетом обновления 2 (SP2);
 Windows Server 2003 R2 (x86 и x64);
 Windows Server 2008 (x86 и x64) с пакетом обновления 2 (SP2);
 Windows Server 2008 R2 (x64).
32–разрядная версия Microsoft SQL Server 2008 R2 можно установить в
следующих ОС:
 Windows Server 2003 SP2;
82
 Windows Server 2008 SP2;
 Windows 2008 R2 64-bit.
Поддерживаемые архитектуры:
 32-разрядная (x86);
 64-разрядная (x64).
Требования к оборудованию для установки:
Для Microsoft Visual Studio 2010:
 процессор с частотой 1,6 ГГц или выше;
 1024 МБ ОЗУ;
 3 ГБ свободного места на диске;
 жесткий диск со скоростью 5400 оборотов в минуту;
 видеоадаптер с поддержкой DirectX 9 и разрешением 1280 x 1024
(или более высоким);
 дисковод DVD-ROM.
Для SQL Server 2008 R2:
 процессор с частотой 1,0 ГГц или выше;
 1 ГБ ОЗУ.
83
3. ПОДГОТОВКА К РАБОТЕ
3.1. Состав дистрибутива
1. Приложение WindowsForms «ДИПЛОМ».
2. База данных «CBGS».
3. Файл с ЛСА «LSA.txt».
3.2. Запуск системы
На начальном этапе оператор компании-заказчика производит импорт базы
данных, далее
производится
инсталляция
приложения
на
рабочее
место
пользователя. После этого осуществляется открытие и запуск приложения.
3.3. Проверка работоспособности системы
Если при запуске приложения пользователю не выводится сообщений об
ошибке, значит, установка приложения прошла успешно.
84
4. ОПИСАНИЕ ОПЕРАЦИЙ
4.1. Операция «Выбор ДИ»
Деловая игра выбирается в стартовой форме, которая выводится игроку на
экран сразу после запуска приложения.
4.1.1. Условия выполнения операции «Выбор ДИ»
Операция выполняется, если установка приложения и базы данных на
рабочем месте игрока прошли успешно, и приложение было запущено.
4.1.2. Подготовительные действия
Не требуются.
4.1.3. Основные действия
Нажать на кнопку с выбранной ДИ.
4.1.4. Заключительные действия
Нажать на кнопку с выбранной ДИ.
4.1.5. Ресурсы, расходуемые на операцию «Выбор ДИ»
Время на выполнение SQL-запроса для выбора существующих в БД
деловых игр и построение формы.
4.2. Операция «Взаимодействие с ресурсом»
Ресурс выбирается в форме взаимодействия с ресурсами.
4.2.1. Условия выполнения операции «Взаимодействие с ресурсом»
Операция выполняется, если для текущей сцены в БД хранится более
одного игрового ресурса и путь к файлу с ресурсом обращается к существующему
в указанном расположении файлу.
4.2.2. Подготовительные действия
Выбрать ДИ (на начальном этапе) или действие (во время игры).
4.2.3. Основные действия
Нажать на кнопку с выбранным для изучения ресурсом.
85
4.2.4. Заключительные действия
Если игрок ознакомился со всеми ресурсами, с которыми хотел,
необходимо нажать на кнопку «Перейти к выполнению задания».
4.2.5. Ресурсы, расходуемые на операцию «Взаимодействие с ресурсом»
Время на выполнение SQL-запроса для выбора существующих в БД
ресурсов и построение формы.
4.3. Операция «Выбор действия»
Действие выбирается в форме выбора действий.
4.3.1. Условия выполнения операции «Выбор действия»
Операция выполняется, если для текущей сцены в БД хранится более
одного действия.
4.3.2. Подготовительные действия
Выбрать ДИ (на начальном этапе) или нажать на кнопку «Перейти к
выполнению задания» на форме взаимодействия с ресурсами (во время игры).
4.3.3. Основные действия
Нажать на кнопку с выбранным действием.
4.3.4. Заключительные действия
Нажать на кнопку с выбранным действием.
4.3.5. Ресурсы, расходуемые на операцию «Выбор действия»
Время на выполнение SQL-запроса для выбора существующих в БД
действий и построение формы.
4.4. Операция «Возвращение к списку ДИ»
Возвращение к стартовой форме со списком ДИ возможно при нажатии на
соответствующую кнопку в конечной форме.
4.4.1. Условия выполнения операции «Возвращение к списку ДИ»
Игроку необходимо пройти выбранную им текущую деловую игру до
конца.
86
4.4.2. Подготовительные действия
Пройти текущую деловую игру до конца.
4.4.3. Основные действия
Нажать на кнопку возврата к списку ДИ.
4.4.4. Заключительные действия
Нажать на кнопку возврата к списку ДИ.
4.4.5. Ресурсы, расходуемые на операцию «Возвращение к списку ДИ»
Время на построение формы.
87
5. АВАРИЙНЫЕ СИТУАЦИИ
В случае если файл со строкой ЛСА не был установлен, после выбора ДИ в
стартовой форме возникнет следующая ошибка (см. рис. D.1):
Рисунок D.1. Отсутствие базы данных на рабочем месте игрока
В данном случае необходимо обратиться к оператору игры на стороне
заказчика. При прочих программных ошибках необходимо обратиться к
разработчикам СКДИ за получением подробностей о том, как можно устранить
ошибку.
88
6. РЕКОМЕНДАЦИИ ПО ОСВОЕНИЮ
6.1. Контрольный пример
В начале игры выбирается ДИ, в качестве ДИ была выбрана игра
«Прототип» (см. рис. D.2). В игре «Прототип» существует четыре сцены:
«Сцена 1», «Сцена 2», «Безусловная сцена 1», «Безусловная сцена 2». Безусловная
сцена не предполагает наличия формы выбора действий.
Рисунок D.2. Стартовая сцена
После выбора игры осуществляется переход к первой сцене – «Сцена 1»,
для неё формируется форма взаимодействия с игровыми ресурсами, на которую
выводятся все ресурсы данной сцены. На рисунке D.3 показано что произойдёт,
если Игрок выберет «Ресурс С». После выбора ресурса производится открытие
файла с выбранным ресурсом.
Рисунок D.3. Выбора ресурса «Ресурс С» на форме взаимодействия с ресурсами
89
Если Игрок не хочет изучать теоретический материал, представленный на
форме взаимодействия с ресурсами, или он уже ознакомился со всеми
необходимыми ресурсами, он должен нажать кнопку «Перейти к выполнению
задания». После перехода к выполнению задания, Игрок видит форму выбора
действия для сцены «Сцена 1» (см. рис. D.4).
Если Игрок выбирает «Действие 1.2», Игроку выводится форма для
взаимодействия с ресурсами сцены «Сцена 2», предположим, что на этот раз Игрок
уже ранее ознакомился с игровыми ресурсами и сразу перешёл к выполнению
задания в сцене «Сцена 2» нажав на кнопку «Перейти к выполнению задания». На
сцене «Сцена 2» Игроку выводится набор действий для текущей сцены, который
включает в себя «Действие 2.1» и «Действие 2.2».
Рисунок D.4. Выбора действия «Действие 1.2» на форме выбора действия в сцене «а1»
Игрок выбирает «Действие 2.1» (см. рис. D.5), в базе данных код этого
действия закодирован как «P3», по строке ЛСА осуществляется переход к сцене
«а3» или «Безусловная сцена 1» (см. рис. D.6).
90
Рисунок D.5. Выбора действия «Действие 2.1» на форме выбора действия в сцене «а2»
Для всех сцен игры предполагается наличие формы взаимодействия с
ресурсами, в том числе данная форма предусмотрена для безусловных сцен.
Безусловные сцены выводятся на экран с целью отображения перехода по ЛСА,
Игрок в них нажимает на кнопку «Далее» и переходит к следующим сценам в
соответствии со сценарием игры.
Рисунок D.6. Переход к безусловной сцене «а3»
91
После того как была пройдена сцена «Безусловная сцена 1», игра
заканчивается и Игроку выводится конечная сцена. В конечной сцене Игрок может
вернуться к стартовой сцене со списком всех деловых игр, нажав на кнопку со
стрелкой. При наведении на кнопку перехода к стартовой сцене
всплывающая подсказка «Перейти к выбору ДИ» (см. рис. D.7):
Рисунок D.7. Конечная сцена
92
появляется