Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Программное проектирование деловых игр

Программное проектирование деловых игр

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 07.07.2016
Размер файла 2,3 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

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

Список терминов и сокращений

СКДИ

-

Студия компетентностных деловых игр

ОМ

-

Операционная модель

АМ

-

Автоматная модель

ОА

-

Операционный автомат

УА

-

Управляющий автомат

ДИ

-

Деловая игра

КДИ

-

Кометентностная деловая игра

ЛСА

-

Логическая схема алгоритма

БД

-

База данных

ИИС

-

Интеллектуальная информационная система

БП

-

Бизнес-процесс

РБП

-

Рабочий бизнес-процесс

КО

-

Карта операций

Оп

-

Операции

ТПР

-

Точка принятия решений

ТЗ

-

Техническое задание

Введение

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

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

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

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

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

По сравнению со стандартными подходами к обучению (например, лекционными занятиями, тестами или практическими заданиями), организация процесса обучения через игру является более наглядным способом получения компетенций. Использование игр для обучения получило термин «геймификация» [1]. С помощью Студии компетентностных деловых игр предполагается разрабатывать и проводить бизнес_игры, которые обеспечивают следующие преимущества:

1. Виден прогресс Игрока: на каждом этапе игры оценивается уровень компетенций Игрока, в конце игры вычисляется суммарный уровень компетенций.

2. Выполняются задания с различной структурой: разнообразие заданий для Игрока определяется ресурсами, которые будут разработаны.

3. Поощрение Игрока: ход игры зависит от результата Игрока на текущем этапе (например, если Игрок выполнил правильно сложное задание, то ему присваивается оценка выше или «штраф» меньше).

4. Наличие обратной связи от Игроков для корректировки деловой игры.

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

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

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

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

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

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

Для достижения поставленной цели были сформулированы следующие задачи:

1. Обзор и сравнение систем для проектирования и проведения деловых игр.

2. Определение функциональных требований к операционной модели.

3. Проектирование базы данных для подсистемы проведения.

4. Проектирование диалоговых форм.

5. Реализация операционной модели на языке программирования высокого уровня.

6. Разработка технической документации - технического задания (представлено в приложении C) и руководства пользователя (представлено в приложении D).

Глава 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 ef?ciency (over time and/or space), information compression (data to knowledge), extrapolated reasoning» [3].

В основе СКДИ лежит деловая игра. Если давать определение ДИ более обобщённо, то можно воспользоваться определением, данным Робертом Виллсом: «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].

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

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

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

Функция ОА задаётся следующим набором следующих множеств:

1. Множество входных слов , вводимых в автомат в качестве операндов.

2. Множество выходных слов представляющих результаты операций.

3. Множество внутренних слов , используемых для представления информации в процессе выполнения операций (можно считать, что входные и выходные слова совпадают с определенными внутренними).

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

5. Множество логических условий , где , а -- булева функция; это i-ое условие из множества всех условий. Эта запись проверяет выполнение условия над множеством слов S. Если условие выполняется, то , иначе .

Функция ОА считается заданной, если определено каждое из множеств D, R, S, Y, X. Время не является аргументом функции ОА, так как функция ОА определяет набор операций и логических условий, которые могут выполняться ОА, но не последовательность их выполнения во времени. С помощью этой функции нельзя описать вычислительный процесс, можно лишь определить средства, которые будут использоваться в вычислительном процессе.

Для того чтобы описать бизнес-процесс, поступающий из подсистемы проектирования в подсистему проведения, в частности в управляющий автомат, используется язык Логических Схем Алгоритмов, разработанный А.А. Ляпуновым. Описание составляющих ЛСА приведено далее: «Логическая схема представляет собой строку из операторов и логических условий, называемых членами схемы. После каждого логического условия начинается стрелка, оканчивающаяся перед одним из членов схемы, либо в конце строки» [8].

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

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

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

Форма взаимодействия с ресурсами поделена на 4 блока: входы, выходы, управление, механизмы. Входами являются файлы для ознакомления Игроком, данные файлы не доступны для редактирования, осуществляется только чтение файла. Примером входа может быть изображение с иллюстрацией к заданию. Ресурсами в блоке управления также являются файлы для чтения (чаще всего файлы, содержащие текст в формате pdf, doc, xls и т. п.). Отличие ресурсов в блоке входов от ресурсов блока управления состоит в том, что под управлением понимаются документы, распоряжения, любые другие документы, влияющие на порядок и ход выполнения действия (процесса). Примером ресурса в блоке управления может быть должностная инструкция, описанная в файле с форматом doc. Механизмом -- это команда, необходимая для выполнения действия (процесса). Например, если Игрок выбирает действие «написать ТЗ», в качестве механизма будет системная команда, которая запускает Microsoft Office Word 2010. Выходами являются файлы, которые предназначены для редактирования и сохраняются Игроком после взаимодействия с ними.

Использование ДИ в учебном процессе реализует принципы «геймификации» (использование игровых механизмов в неигровых сферах) для повышения интереса пользователей к процессу обучения. По прогнозам компании «Gartner» [9] 40% из списка «Global 1000 organizations» к 2015 году будут использовать в своей работе «геймификацию» - комплекс мотивационных управленческих техник, заимствованных у компьютерных игр. Для реализации бизнес-процессов в ДИ с помощью логико-математических правил будет использована операционная модель, для представления хода игры в автоматной модели будет использован язык логических схем алгоритмов.

1.2 Обзор и анализ существующих автоматизированных деловых игр

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

Для анализа аналогов СКДИ на российском рынке были выбраны следующие автоматизированные ДИ: SimVenture и Simultrain. При проведении анализа использовалось сравнение игр по критериям, показателям, индикаторам (см. прил. A).

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

1. Диалог с пользователем.

2. Команды управляющей модели.

3. Стоимости лицензий.

4. Встроенные БП.

5. Рейтинг игрока.

6. Тип доступа к игре.

С помощью показателя может быть задана количественная оценка критерия. Ниже приведён список показателей для каждого критерия:

1. Диалог с пользователем:

a. Интуитивно понятный интерфейс.

b. Предупреждение об ошибках.

c. Мультиязычность.

2. Команды управляющей модели:

a. Расширяемость команд.

b. Адаптивность игры к результатам игрока.

3. Стоимости лицензий:

a. Бесплатные демо-версии.

b. Есть ли срок лицензии.

c. Наличие скидок.

4. Встроенные БП:

a. Управляющие.

b. Операционные.

c. Поддерживающие.

5. Рейтинг игрока:

a. Наличие встроенного механизма оценивания.

b. Ранжирование игроков.

c. Бонусы за лидерство.

6. Тип доступа к игре:

a. Для ВУЗов.

b. Корпоративный.

c. Для физических лиц.

Индикаторы используются для того, чтобы указать наличие или отсутствие критерия для рассматриваемой деловой игры. Условное обозначение для наличия критерия в ДИ «+», для отсутствия критерия в ДИ «-».

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

1.3 Описание подсистем Студии компетентностных деловых игр

СКДИ состоит из шести подсистем:

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

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

3. Подсистема мониторинга.

4. Подсистема измерения.

5. Подсистема анализа.

6. Подсистема корректировки.

Подсистема проектирования отвечает за приведённые ниже функции:

1. Проектирование сценариев на начальном этапе разработки ДИ.

2. Перепроектирование сценариев, если подсистемой корректировки были выявлены недочёты в сценарии ДИ.

3. Разработку сценариев деловых игр.

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

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

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

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

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

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

Более подробное разделение СКДИ на подсистемы, а также порядок взаимодействия подсистем приведены на рисунке 1.1:

Рисунок 1.1. Подсистемы Студии компетентностных деловых игр

1.4 Модель прецедентов для операционной модели

Модель прецедентов описывает функциональные требования к СКДИ и используется в качестве модели «to be». Каждая описанная функция является результатом выявления ценных для субъекта задач. Чтобы определить задачи субъекта необходимо определить, какие функции или действия субъект выполняет по отношению к системе и что он хочет получить в результате взаимодействия с системой. Распределение функциональных требований по субъектам и прецедентам приведено в таблице 1.1:

Таблица 1.1. Распределение требований по субъектам и прецедентам

№

Требование

Субъект

Прецедент

1

На экран Игроку выводится стартовая сцена со списком деловых игр, Игрок делает выбор деловой игры.

Игрок

Выбор ДИ в стартовой сцене

2

Для принятия решения о дальнейшем ходе развития игры, Игрок должен выбрать действие на сцене. Несколько действий на сцене символизируют наличие условного оператора if, если действие одно, то наличие выбора в связи с условием игры не предполагается (действие выбирается по умолчанию, сцена выбора действий игроку не выводится, выбранное действие будет выведено Игроку в сцене взаимодействия с ресурсами).

Игрок

Выбор действия на сцене действий

3

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

Игрок

Обращение к ресурсу (ресурсам) в сцене взаимодействия с ресурсами

4

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

Игрок

Вычисление состояния игры

5

Сцена - является точкой принятия решения, в сцене выбора действия Игрок должен совершить (выбрать) действие. Действия сцены выбираются из БД СКДИ по идентификатору сцены. Выбранные из БД СКДИ действия располагаются на сцене.

БД СКДИ

Вывод сцены выбора действий на экран

6

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

БД СКДИ

Вывод сцены взаимодействия с ресурсами на экран

7

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

Регистр состояний игры

Запись кода текущего состояния игры в регистр состояний игры

8

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

Регистр состояний игры

Получение идентификатора следующей сцены

Диаграмма прецедентов (см. рис. 1.2) приписывает прецеденты к субъектам. Она также позволяет пользователю установить отношения между прецедентами, конечно, если такие отношения существуют.

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

Чтобы представить полную модель прецедентов необходимо более подробное описание элементов диаграммы (прецедентов и субъектов).

1.4.1 Документирование прецедентов

Каждый прецедент должен быть описан с помощью документально зафиксированного потока событий (flow of events). Соответствующий текстовый документ определяет, что должна делать система, когда субъект инициирует прецедент. Потоки событий для прецедентов описаны в таблицах 1.2 - 1.9:

Таблица 1.2. Прецедент 1: Выбор ДИ в стартовой сцене

Краткое описание

Прецедент дает возможность Игроку выбрать деловую игру.

Актеры

Игрок.

Предусловия

Игрок запустил приложение.

Основной поток

1. Игроку выводится стартовая сцена.

2. Игрок выбрал деловую игру на сцене.

Альтернативные потоки

Если Игрок завершил игру, то вывести конечную сцену игры.

Постусловия

Игрок выбрал деловую игру.

Таблица 1.3. Прецедент 2: Выбор действия на сцене действий

Краткое описание

Прецедент дает возможность Игроку выбрать действие на сцене выбора действий.

Актеры

Игрок.

Предусловия

Игрок выбрал ДИ в стартовой сцене или Игрок закончил взаимодействие с ресурсами.

Основной

Поток

1. Вывести действия на экран.

2. Игрок выбирает действие на сцене.

Альтернативные потоки

Если в БД нет сцены с полученным кодом сцены, то Игроку выводится сообщение об ошибке, производится переход к предыдущей сцене.

Постусловия

Игрок выбрал действие.

Таблица 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. По коду сцены найти сцену в БД.

3. Получить действия сцены из БД.

4. Сформировать сцену взаимодействия с ресурсами.

Альтернативные потоки

Если в БД не был найден код сцены, то Игроку будет выведено сообщение об ошибке.

Постусловия

На сцену было/были выведены действие/действия.

Таблица 1.8. Прецедент 7: Запись кода текущего состояния игры в регистр состояний игры

Краткое описание

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

Актеры

Регистр состояний игры.

Предусловия

Было вычислено текущее состояние игры.

Основной

Поток

1. Записать приведённая к виду двоичного кода последовательность переходов в регистр состояний игры.

2. Изменить значение логической переменной для ОМ на false.

Альтернативные потоки

Если, приведённая к виду двоичного кода последовательность переходов = null, то Игроку будет выведено сообщение об ошибке.

Постусловия

Код текущего состояния игры записан в регистр состояний игры.

Таблица 1.9. Прецедент 8: Получение идентификатора следующей сцены

Краткое описание

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

Актеры

Регистр состояний игры.

Предусловия

В регистре состояний игры было изменено значение логической переменной для ОМ с false на true.

Основной

Поток

1. Обратиться к регистру состояний.

2. Считать идентификатор следующей сцены.

Альтернативные потоки

Если значение логической переменной для ОМ = false и идентификатор следующей сцены = null, то выдать Игроку сообщение об ошибке.

Постусловия

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

1.4.2 Моделирование видов деятельности

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

Описательная спецификация прецедента «Выбор ДИ в стартовой сцене» приведена в таблице 1.10:

Таблица 1.10. Установление действий в основном и альтернативных потоках для прецедента «Выбор ДИ в стартовой сцене»

№

Формулировка прецедента

Состояние вида деятельности

1

Игроку выводится стартовая сцена.

Вывести стартовую сцену со списком.

2

Игрок выбрал деловую игру на сцене.

Выбирать ДИ из списка игр.

3

Если Игроку завершил игру, то будет выведена конечная сцена.

При условии, что завершил игру: вывести конечную сцену.

Диаграмма активности для прецедента «Выбор ДИ в стартовой сцене» изображена на рисунке 1.3:

Рисунок 1.3. Диаграмма активности для прецедента «Выбор ДИ в стартовой сцене»

Описательная спецификация прецедента «Выбор действия на сцене действий» приведена в таблице 1.11:

Таблица 1.11. Установление действий в основном и альтернативных потоках для прецедента «Выбор действия на сцене действий»

№

Формулировка прецедента

Состояние вида деятельности

1

Вывести действия на экран.

Вывести действия на сцену.

2

Игрок выбирает действие на сцене.

Выбрать действие.

3

Если в БД нет сцены с полученным кодом сцены, то Игроку выводится сообщение об ошибке, производится переход к предыдущей сцене.

При условии, что в БД нет сцены с полученным кодом: вывести сообщение об ошибке, прейти к предыдущей сцене.

Диаграмма активности для прецедента «Выбор действия на сцене действий» изображена на рисунке 1.4:

Рисунок 1.4. Диаграмма активности для прецедента «Выбор действия на сцене действий»

Описательная спецификация прецедента «Обращение к ресурсу (ресурсам) в сцене взаимодействия с ресурсами» приведена в таблице 1.12:

Таблица 1.12. Установление действий в основном и альтернативных потоках для прецедента «Обращение к ресурсу (ресурсам) в сцене взаимодействия с ресурсами»

№

Формулировка прецедента

Состояние вида деятельности

1

Вывести ресурсы на экран.

Выбрать ресурс.

2

Игрок выбирает ресурс на сцене.

Нажать кнопку с выбранным ресурсом.

Диаграмма активности для прецедента «Обращение к ресурсу (ресурсам) в сцене взаимодействия с ресурсами» изображена на рисунке 1.5:

Рисунок 1.5. Диаграмма активности для прецедента «Обращение к ресурсу (ресурсам) в сцене взаимодействия с ресурсами»

Описательная спецификация прецедента «Вычисление состояния игры» приведена в таблице 1.13:

Таблица 1.13. Установление действий в основном и альтернативных потоках для прецедента «Вычисление состояния игры»

№

Формулировка прецедента

Состояние вида деятельности

1

Получить идентификатор выбранного действия.

Получить код выбранного действия..

2

Найти в БД соответствующее идентификатору действия условие перехода.

Найти в БД условие перехода.

3

Привести условие перехода к виду двоичного кода.

Преобразовать условие перехода в двоичный код.

4

Если по идентификатору выбранного действия в БД СКДИ не было найдено условие перехода, то Игроку будет выведено сообщение об ошибке.

При условии, что по коду выбранного действия в БД СКДИ не было найдено условие перехода: вывести сообщение об ошибке.

Диаграмма активности для прецедента «Вычисление состояния игры» изображена на рисунке 1.6:

Рисунок 1.6. Диаграмма активности для прецедента «Вычисление состояния игры»

Описательная спецификация прецедента «Вывод сцены выбора действий на экран» приведена в таблице 1.14:

Таблица 1.14. Установление действий в основном и альтернативных потоках для прецедента «Вывод сцены выбора действий на экран»

№

Формулировка прецедента

Состояние вида деятельности

1

Получить код сцены.

Получить код сцены.

2

По коду сцены найти сцену в БД.

Найти сцену в БД.

3

Получить действия сцены из БД.

Получить действия.

4

Сформировать сцену выбора действий.

Сформировать сцену.

5

Если в БД не был найден код сцены, то Игроку будет выведено сообщение об ошибке, осуществлён переход к предыдущей сцене.

При условии, что в БД не найден код сцены: вывеси сообщение об ошибке, перейти к предыдущей сцене.

Диаграмма активности для прецедента «Вывод сцены выбора действий на экран» изображена на рисунке 1.7:

Рисунок 1.7. Диаграмма активности для прецедента «Вывод сцены выбора действий на экран»

Описательная спецификация прецедента «Вывод сцены взаимодействия с ресурсами на экран» приведена в таблице 1.15:

Таблица 1.15. Установление действий в основном и альтернативных потоках для прецедента «Вывод сцены взаимодействия с ресурсами на экран»

№

Формулировка прецедента

Состояние вида деятельности

1

Получить код сцены.

Получить код сцены.

2

По коду сцены найти сцену в БД.

Найти сцену в БД.

3

Получить ресурсы сцены из БД.

Получить ресурсы.

4

Сформировать сцену выбора действий.

Сформировать сцену.

5

Если в БД не был найден код сцены, то Игроку будет выведено сообщение об ошибке, осуществлён переход к предыдущей сцене.

При условии, что в БД не найден код сцены: вывеси сообщение об ошибке, перейти к предыдущей сцене.

Диаграмма активности для прецедента «Вывод сцены взаимодействия с ресурсами на экран» изображена на рисунке 1.8:

Рисунок 1.8. Диаграмма активности для прецедента «Вывод сцены взаимодействия с ресурсами на экран»

Описательная спецификация прецедента «Запись кода текущего состояния игры в регистр состояний игры» приведена в таблице 1.16:

Таблица 1.16. Установление действий в основном и альтернативных потоках для прецедента «Запись кода текущего состояния игры в регистр состояний игры»

№

Формулировка прецедента

Состояние вида деятельности

1

Записать приведённая к виду двоичного кода последовательность переходов в регистр состояний игры.

Записать последовательность переходов в виде двоичного кода в регистр состояний игры.

2

Изменить значение логической переменной для ОМ на false.

Изменить значение логической переменной для ОМ на false.

3

Если, приведённая к виду двоичного кода последовательность переходов = null, то будет выведено сообщение об ошибке.

Если приведённая к виду двоичного кода последовательность переходов = null: вывести сообщение об ошибке.

Диаграмма активности для прецедента «Запись кода текущего состояния игры в регистр состояний игры» изображена на рисунке 1.9:

Рисунок 1.9. Диаграмма активности для прецедента «Запись кода текущего состояния игры в регистр состояний игры»

Описательная спецификация прецедента «Получение идентификатора следующей сцены» приведена в таблице 1.17:

Таблица 1.17. Установление действий в основном и альтернативных потоках для прецедента «Получение идентификатора следующей сцены»

№

Формулировка прецедента

Состояние вида деятельности

1

Обратиться к регистру состояний.

Обратиться к регистру состояний.

2

Считать идентификатор следующей сцены.

Считать идентификатор следующей сцены.

3

Если значение логической переменной для ОМ = false и идентификатор следующей сцены = null, то выдать Игроку сообщение об ошибке.

При условии, что значение логической переменной для ОМ = false и идентификатор следующей сцены = null: вывести сообщение об ошибке.

Диаграмма активности для прецедента «Получение идентификатора следующей сцены» изображена на рисунке 1.10:

Рисунок 1.10. Диаграмма активности для прецедента «Получение идентификатора следующей сцены»

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

Глава 2. Проектирование операционной модели

2.1 Проектирование базы данных

Модель данных БД представляет собой ER-модель, которая описывает на разных уровнях (концептуальном, логическом, физическом) набор связанных между собой сущностей, сгруппированных по функциональным областям.

К этапам разработки модели данных относятся:

1. Разработка концептуальной модели данных.

2. Создание логической модели данных.

3. Разработка физической модели данных.

2.1.1 Концептуальная модель данных

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

Для СКДИ концептуальная модель представлена на рисунке 2.1 и состоит из следующих сущностей:

1. BG (ДИ) - набор деловых игр или дисциплин, которые будут предложены заказчику и выведены списком в стартовой сцене.

2. Scenes (Сцены) - представляют собой низший уровень после проведения декомпозиции сценария, являются точками принятия решения Игрока.

3. Actions (Действия) - сцены выбора действий содержат в себе действия, которые являются процессами, из которых складывается сценарий (бизнес-процесс).

4. Resources (Ресурсы) - сцены обращения к ресурсам содержит в себе ресурс или набор ресурсов, с которыми необходимо взаимодействовать для выполнения какого-либо действия.

5. Users (Пользователи) - в качестве пользователя рассматривается любой человек, который зарегистрирован в системе СКДИ, данная сущность включает в себя как Игроков, так и разработчиков, тестировщиков и прочих людей, непосредственно нуждающихся в доступе к автоматизированной ДИ.

6. User_roles (Роли пользователей) - данная сущность определяет права пользователя (например, конкретный пользователь с ролью разработчик имеет право редактировать некоторые из программных модулей).

Рисунок 2.1. Концептуальная модель данных

2.1.2 Логическая модель данных

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

В логической модели данных можно выделить следующие сущности:

1. BG (ДИ).

2. Users (Пользователи).

3. User_roles (Роли пользователей).

4. Scenes (Сцены).

5. Actions (Действия).

6. Resources (Ресурсы).

У деловой игры может быть множество пользователей, и множество пользователей могут играть в одну игру, поэтому между сущностями «BG» и «Users» установлена связь «многие-ко-многим», как показано на рисунке 2.2:

Рисунок 2.2. Связь между сущностями Пользователи и ДИ

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

Рисунок 2.3. Связь между сущностями Пользователи и Роли пользователей

Одна ДИ состоит из множества Сцен, но одна Сцена не может использоваться в нескольких играх. Однократное использование Сцены вызвано тем, что для разных ДИ в зависимости от Сцены будет подтягиваться из БД СКДИ разный набор ресурсов и действий. Таким образом, между сущностями «BG» и «Scenes» установлена связь «один-ко-многим», как показано на рисунке 2.4:

Рисунок 2.4. Связь между сущностями ДИ и Сцены

В одну сцену можно вывести несколько действий для реализации ТПР Игрока. Действие, которое уже было разработано может использоваться неоднократно в разных сценах, следовательно, между сущностями «Scenes» и «Actions» должна быть установлена связь «многие-ко-многим», как показано на рисунке 2.5:

Рисунок 2.5. Связь между сущностями Сцены и Действия

Аналогично для ресурсов, сцена состоит из нескольких ресурсов для реализации ТПР Игрока. Ресурс, который уже был разработан, может использоваться неоднократно в разных сценах, следовательно, между сущностями «Scenes» и «Resources» должна быть установлена связь «многие-ко-многим», как показано на рисунке 2.6:

Рисунок 2.6. Связь между сущностями Сцены и Ресурсы

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

Рисунок 2.7. Логическая модель данных

2.1.3 Физическая модель данных

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

Таблица «BG» представляет собой описание сущности Деловая игра. В таблице 2.1 приводится описание полей таблицы:

Таблица 2.1. Таблица «BG»

Поле

Тип значения

Допускаются пустые значения

Примечание

id_BG

numeric(18, 0)

Нет

Идентификатор ДИ

BG_name

nchar(100)

Нет

Название ДИ

LSA_filepath

nchar(600)

Нет

Путь к файлу со строкой ЛСА

Таблица «BG_users» является вспомогательной таблицей и служит для обеспечения связи многие-ко-многим между сущностями ДИ и Пользователь. В таблице 2.2 приводится описание полей таблицы:

Таблица 2.2. Таблица «BG_users»

Поле

Тип значения

Допускаются пустые значения

Примечание

Id

numeric(18, 0)

Нет

Идентификатор

id_BG

numeric(18, 0)

Нет

Идентификатор ДИ

id_user

numeric(18, 0)

Нет

Идентификатор сцены

Таблица «Users» представляет собой описание сущности Пользователь. В данной таблице хранится информация обо всех зарегистрированных в системе пользователях и сотрудниках, взаимодействующих с СКДИ. В таблице 2.3 приводится описание полей таблицы:

Таблица 2.3. Таблица «Users»

Поле

Тип значения

Допускаются пустые значения

Примечание

id_user

numeric(18, 0)

Нет

Идентификатор пользователя

user_name

nchar(100)

Нет

ФИО пользователя

e-mail

nchar(100)

Да

Электронный адрес пользователя

Таблица «Roles» представляет собой описание сущности Роль пользователя. В данной таблице хранится информация о ролях пользователей СКДИ. В таблице 2.4 приводится описание полей таблицы:

Таблица 2.4. Таблица «Roles»

Поле

Тип значения

Допускаются пустые значения

Примечание

id_role

numeric(18, 0)

Нет

Идентификатор роли пользователя

role_name

nchar(10)

Нет

Роль пользователя

Editor

Bit

Нет

Признак того, что пользователь с данной ролью обладает правом на редактирование программных модулей

reg_date

Date

Да

Дата регистрации в СКДИ

Таблица «Game_scenes» представляет собой описание сущности Сцена. В данной таблице хранится информация о сценах СКДИ. В таблице 2.5 приводится описание полей таблицы:

Таблица 2.5. Таблица «Game_scenes»

Поле

Тип значения

Допускаются пустые значения

Примечание

id_scene

numeric(18, 0)

Нет

Идентификатор сцены

id_action

numeric(18, 0)

Нет

Идентификатор действия

id_resource

numeric(18, 0)

Да

Идентификатор ресурса

operation_name

nchar(10)

Нет

Наименование прецедента (операции)

id_BG

numeric(18, 0)

Нет

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены