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

advertisement
ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное
учреждение высшего профессионального образования
"Национальный исследовательский университет
"Высшая школа экономики"
Пермский филиал
Факультет бизнес-информатики
Кафедра информационных технологий в бизнесе
УДК 004 .853
ТЕМА РАБОТЫ
Разработка управляющей модели программного комплекса для
проведения деловых игр
Работу выполнил студент
группы БИ-10-2
4 курса факультета бизнес-информатики
Семков Н.А.
Научный руководитель:
к.т.н., доцент кафедры информационных
технологий в бизнесе
Викентьева О.Л.
“6” июня 2014 г.
Пермь 2014
Оглавление
Введение .................................................................................................................. 3
Глава 1. Анализ системы СКДИ ........................................................................ 5
1.1 Постановка задачи ......................................................................................... 5
1.2 Структура студии компетентностных деловых игр ................................... 5
1.3 Роль автоматной модели в СКДИ ................................................................ 7
1.4 Способы представления сценария деловой игры ....................................... 9
1.5 Обзор аналогов автоматной модели........................................................... 11
1.6 Тестовый пример .......................................................................................... 13
Глава 2. Этапы разработки алгоритма для АМ............................................ 14
2.1 Алгоритм работы логических схем алгоритмов ....................................... 14
2.2 Загрузка сценария деловой игры ................................................................ 16
2.3 Проверка ЛСА на корректность ................................................................. 18
2.4 Передача кода сцены в регистр состояний ................................................ 21
2.5 Чтение и анализ двоичного кода из регистра состояния ......................... 23
2.6 Программная реализация ............................................................................ 26
2.7 Алгоритм работы автоматной модели ....................................................... 27
2.8 Интеграция автоматной и операционной моделей ................................... 32
2.9 Основные функции режима отладки ......................................................... 33
Заключение ........................................................................................................... 35
Библиографический список .............................................................................. 36
Приложение 1. Техническое задание ............................................................... 37
2
Введение
Ужесточение требований работодателей к выпускникам вузов, сильная
конкуренция на рынке труда делает невозможным использование традиционных
подходов к обучению студентов. Решением данной проблемы является внедрение
новых стандартов образования.
Данные стандарты предполагают наличие у выпускников определенных
профессиональных компетенций, которые будут непосредственно полезны при
приеме на работу. Выработка таких компетенций на сегодняшний момент является
основным вопросом высшего профессионального образования.
Данный вопрос может решить студия компетентностных деловых игр
(СКДИ). Данный программный продукт предполагает выработку нужных
профессиональных компетенций у студентов в период обучения. Компетенции
предполагают знания и умения выпускника принимать различные решения,
основываясь на полученном опыте.
Студия компетентностных деловых игр представляет собой систему,
основными подсистемами которой являются подсистема проектирования и
подсистема проведения. Подсистема проведения, в свою очередь, состоит из
автоматной и операционной моделей. Автоматная модель отвечает за чтение
сценариев деловых игр, тогда как операционная модель отвечает за использование
ресурсов, предназначенных для взаимодействия с пользователем.
Основной целью данной работы является разработка автоматной модели
(АМ) студии компетентностных деловых игр, являющейся элементом системы
проведения
деловых
игр.
Объектом
исследования
является
студия
компетентностных деловых игр; предметом исследования – автоматная модель.
Для достижения поставленной цели требуется решить следующие задачи:
 выполнить анализ предметной области (способы представления
сценария деловой игры, способы реализации автоматной модели);
 разработать алгоритм функционирования автоматной модели;
 разработать техническое задание на программный модуль;
 разработать алгоритм программный модуль автоматной модели;
3
 выполнить
интеграцию операционной и автоматной моделей и
провести тестирование полученной подсистемы проведения деловой
игры на контрольном примере.
Результатом работы является программный модуль, реализующий
автоматную модель
подсистемы проведения деловых игр, а также
подсистема проведения деловых игр, полученная путем интеграции данного
модуля с операционной моделью.
4
Глава 1. Анализ системы СКДИ
1.1 Постановка задачи
Для определения основной задачи выпускной квалификационной работы,
следует обозначить проблему данного исследования. Как уже было обозначено
ранее – основным критерием для работодателей является наличие компетенций в
определенной
устройства
на
профессиональной
работу
на
области.
должность
Так,
основным
программиста
критерием
являются
для
навыки
программирования. Еще лучше, если будет опыт в разработке программного
обеспечения (ПО) на различных языках программирования – тогда
у
потенциального работника будет больше шансов при устройстве на нужную
работу.
Поскольку новые образовательные стандарты предполагают выработку
компетенции в ходе обучения, основной проблемой становится выбор наиболее
продуктивного метода формирования компетенций в процессе обучения. Для этого
следует
рассмотреть
подходы
к
обучению,
направленные
на
развитие
познавательной, личностной и коммуникативной деятельности студентов [4].
Как нельзя лучше под новые образовательные стандарты подходят активные
формы обучения. Данные методы направлены на развитие самостоятельного
мышления у студентов/учеников, а так же его способность квалифицированно
решать профессиональные, временами не стандартные задачи. К активным
методам обучения можно отнести следующие формы обучения – ролевые игры,
разбор практических ситуаций, использование принципов геймификации –
использование компьютерных симуляторов, проведение деловых игр [2].
Исходя из этого, основной проблемой становится создание системы,
позволяющей использовать интерактивный подход к обучению с максимальной
полезностью для образовательного процесса.
1.2 Структура студии компетентностных деловых игр
Рассматриваемый
подход
предполагает
разработку
технических,
организационных и методических средств, направленных на формирование
компетенций. Речь идет об использовании компетентностных деловых игр.
5
Под понятием «компетентностная деловая игра» подразумевается некая
информационная система, целью которой является выработка определенного
уровня профессиональных компетенций и их дальнейшее развитие, используя
подход реализации сценариев. Данные сценарии определяются моделями бизнеспроцессов предметной области.
В данном подходе рассматривается создание специальной среды для
разработки и проведения деловых игр – студия компетентностных деловых игр.
Структурная схема СКДИ представлена ниже (Рис. 1.1):
Рисунок 1.1 Структурная схема СКДИ
В студии компетентностных деловых игр можно выделить 2 основных
составляющих: система проектирования и система проведения деловых игр.
Рассмотрим подсистемы СКДИ:
Подсистема проектирования [1]. Данная система предназначена для
разработки сценариев деловых игр, создание моделей предметных областей, на
базе которых выполняются сценарии. Помимо этого, данная система отвечает за
создание контрольно-измерительных и учебно-методических материалов для
проведения игр.
Подсистема проведения [1] отвечает за проведение самой деловой игры,
используя материалы, разработанные в подсистеме проектирования.
Подсистема мониторинга [1] отвечает за мониторинг действий и
результатов игрока во время взаимодействия со студией.
6
Подсистема анализа [1] осуществляет обработку результатов, получение
отчетов о ходе ДИ, состоянии игроков и о качестве методического обеспечения.
Исходя из данных, полученных из подсистемы анализа, подсистема
корректировки [1] предназначена для оперативного вмешательства в ход деловой
игры, а так же создание замечаний и задач на дальнейшую доработку
определенных бизнес-процессов.
Поскольку
реализация
всей
студии
подразумевает
использование
значительного объема ресурсов, как человеческих, так и материальных, целью
данной работы является проектирование и создание автоматной модели,
отвечающей за проведение и управление деловой игрой. Далее будут рассмотрены
уже реализованные подходы к формированию компетенций, их сильные и слабые
стороны.
1.3 Роль автоматной модели в СКДИ
Для определения роли автоматной модели в студии компетентностных
деловых игр, следует рассмотреть в целом работу подсистемы проведения ДИ.
Основными элементами данной
подсистемы будут являться автоматная и
операционная модели, база данных деловых игр, база данных ресурсов и регистр
состояний.
Рассмотрим работу системы со стороны автоматной модели. Пользователь
выбирает интересующую деловую игру. Далее автоматный модуль загружает
необходимый сценарий деловой игры и проверяет его на корректность. После
проверки автоматная модель переходит к первой сцене и передает код данной
сцены в регистр состояния. Далее, операционная модель считывает из регистра код
сцены и загружает ресурсы, необходимые для работы с пользователем. Как только
пользователь закончил работать с текущей сценой, операционная модель
обрабатывает полученные данные в двоичный код и передает его в регистр
состояния. Автоматная модель считывает двоичный код, обрабатывает его для
перехода к следующей сцене. Как только пользователь завершил работу с
последней сценой, операционная модель обрабатывает итоговые данные работы с
текущей деловой игрой и предоставляет их пользователю.
7
На диаграмме прецедентов (рис. 1.2) наглядно отображены основные
функции автоматной модели.
Автоматная модель
Загрузка
сценария (ЛСА)
<<include>>
Проверка ЛСА на
корректность
Выделить
оператор ЛСА
<<Include>>
Сформировать
код сцены
Регистр состояний
Передача сцены
<<include>>
Анализ двоичного
кода
Рисунок 1.2 Диаграмма прецедентов
Основными задачами автоматной модели являются:
 чтение сценария выбранной деловой игры;
 проверка сценария на корректность;
 передача кода сцены в регистр состояний;
 анализ двоичного кода, полученного от операционной модели через
регистр состояний;
 переход к следующему оператору ЛСА, содержащему код следующей
сцены.
Алгоритм работы автоматной модели представлен ниже (рис. 1.3).
8
Начало
Загрузка ЛСА
Проверка ЛСА на
корректность
нет
Корректный
алгоритм
Формирование
сообщения об ошибке
да
Выделение оператора
ЛСА
Формирование кода
сцены
Передает код сцены в
регистр состояний
Нет
Чтение двоичного кода из
регистра состояний
Анализ результатов
Конечная сцена?
Конец
Да
Рисунок 1.3 Диаграмма активности автоматной модели
На диаграмме изображена последовательность выполняемых операций
автоматной модели. Представленный алгоритм работы более подробно будет
описан во второй главе данной работы.
1.4 Способы представления сценария деловой игры
Для дальнейшей работы следует определить, в каком виде будут
представлены сценарии деловых игр для работы автоматной модели. Сценарий
деловой
игры
будет представлять отдельный
бизнес-процесс,
требующий
обобщенного представления вне зависимости от предметной области.
Для представления любого бизнес-процесса вводятся понятия:
 модель унифицированного бизнес-процесса – процесса, содержащего
определенный
набор
данных,
конкретных предприятий;
9
специфичных
для
деятельности
 модель
унифицированного
учебного
бизнес-процесса,
который
включает в себя элементы для контроля формирования компетенций в
процессе обучения. Каждый контрольный элемент, направленный на
оценку знаний пользователя, будет объединен в сцену;
 граф
сценария,
представляющий
собой
граф
с
вершинами,
соответствующими сценам бизнес-процесса. Дуги в таком графе будут
являться условиями перехода между сценами. Данный граф описывает
всевозможные пути в сценарии, отображает последовательность сцен.
Наиболее
простым
и
формализованным
процессом
представления
последовательности сцен, условий перехода между ними, является представление в
виде логических схем алгоритма (ЛСА). Основной причинной использования ЛСА
для представления сцен является компактность описываемых данных. Так как в
подсистеме проведения главные роли играю автоматная и операционная модели, то
всю подсистему проведения деловых игр можно представить в виде устройства
обработки
информации.
Данное
устройство
состоит
из
двух
элементов:
операционной и управляющей частей. На вход операционной части поступают
ресурсы, ранее описанные в подсистеме проектирования. Основные команды
(сцены) для загрузки тех или иных ресурсов поступают в операционную модель из
управляющего автомата. Входной информацией для управляющего автомата будут
являться состояния, которые передает операционная модель (рис. 1.4).
Рисунок 1.4 Управляющий автомат ДИ
10
Принцип программного управления процессом сводится к выполнению
команд, приводящих к достижению поставленной задачи для конкретной деловой
игры. Основным элементом программного управления является микрокоманда, а
набор
микрокоманд
–
микропрограмма.
Основными
способами
описания
микропрограмм являются граф-схемы, матричные схемы алгоритмов и логические
схемы алгоритмов. Из всех основных способов описания микропрограмм
логические схемы алгоритмов являются наиболее удобными: весь алгоритм
записывается в строчку, и данная строка может быть какой угодно длинны. Кроме
того, данный подход к описанию является наименее затратным при программной
реализации: обрабатывать строчку гораздо удобнее, нежели обработка матричного
представления, либо представления в виде графов [8].
ЛСА - это конечная строка, состоящая из символов операторов, условий
перехода. Представление ЛСА должно удовлетворять следующим условиям:
 строка начинается начальным оператором и конечным оператором;
 перед начальным и конечным оператором не должно быть стрелок
перехода к той или иной сцене;
 после каждого условия обязательно стоит верхняя стрелка перехода;
 для каждой верхней стрелки с номером i должна быть только одна
нижняя стрелка перехода с аналогичным номером.
В процессе программной реализации данный подход позволит корректно
произвести проверку загрузки алгоритма, а также позволит быстро переходить из
одной сцены к другой в зависимости от условий.
1.5 Обзор аналогов автоматной модели
Для дальнейшего проектирования автоматной модели следует провести
обзор уже существующих решений автоматных моделей. Будут рассмотрены
использованные подходы при реализации автоматных моделей.
Автоматная модель протокола обмена данными
Данная автоматная модель используется автоматизации протокола обмена
данными между сервером и котроллером станков с числовым программным
управлением. Данная автоматная модель построена на основе автомата Мили.
11
Данный автомат отвечает за автоматизацию производства деталей на станках
с ЧПУ. Входной информацией для данной модели является электронный чертеж
для определенного станка. Чертежи поступают на цеховой сервер, где с помощью
автоматной модели перенаправляются на определенный станок.
Автоматная модель композитного документооборота
Данная модель используется в системе электронного документооборота. В
основе рассматриваемой модели рассматривается композитный документооборот,
в котором задействованы как электронные, так и бумажные представления
документов. Модель основана на теории автоматов. В рассматриваемой модели
были описаны методы определенных множеств и их связности.
Описываемый автомат задан следующей пятеркой (A, S, 0 , T, F), где:
 A – алфавит;
 S- множество состояний автомата;
 0 - начальное состояние;
 T – множество завершающих состояний;
 F – функции переходов.
Описанный в данной модели автомат схож с автоматом Мили. На вход
подается входной символ, переход к тому или иному состоянию описан в виде
таблицы. Как результат – на выходе выдается новое состояние. Входные данные в
данной модели в виде документов, которые перенаправляются к определенному
пользователю.
Автоматная модель вычисления времени коллективных мероприятий
Данная автоматная модель отвечает за нахождение интервалов времени для
проведения определенных мероприятий, на которых требуется присутствие
обязательных и необязательных участников. На вход в данную модель поступает
значение каждого участника на определенный временной интервал – 1, если
свободен участник в данный промежуток времени, и 0 – если участник занят.
Выходной информацией является булева функция, организованная выдавать
единичный результат только в том случае, если участники свободны в одно и то же
время.
12
Данная модель выполнена в виде динамического конечного автомата. В
данной модели динамика поведения i-го индивидуума моделируется процессом на
i-м входе автомата, динамика поведения всей группы - процессом на его выходе, а
статическая зависимость состояния группы от состояний индивидуумов - булевой
логической функцией автомата [7].
Рассмотренные модели автоматов в основном основаны на графических или
матричных представлениях логики выполнения. На этом фоне, основным
достоинством логических схем алгоритмов является возможность записи всего
алгоритма в виде строки. Строковое представление удобно разбивать на
составляющие, манипулировать данными элементами, представлять их в иных
видах.
1.6 Тестовый пример
Тестовый пример для проверки работоспособности автоматной модели и
операционной модели выглядит следующим образом:
H0a1p1u1d3p2u2a2p3u3d2a3d1a4k – основной сценарий для проверки
автоматной модели в действии.
A1
0
11
10
A4
A2
0
A3
1
Рисунок 1.5 Граф переходов основного сценария
H0a1d1k – тестовый пример для проверки наличия верхней стрелки
перехода.
H0a1u1k – тестовый пример для поверки наличия нижней стрелки перехода
Проанализировав подсистему проведения деловых игр, а также выделив
основные функции автоматной модели, следует приступить к проектированию
программного модуля, после чего программно реализовать основные функции АМ
и проверить работоспособность разработанного модуля на тестовом примере.
13
Глава 2. Этапы разработки алгоритма для АМ
2.1 Алгоритм работы логических схем алгоритмов
Впервые использование логических схем алгоритмов предложил академик
Ляпунов для описания блок-схем программ. Пример записи алгоритма в виде ЛСА
представлен ниже:
H0 ↓2 A1 P1 ↑1 ↓3 ↓1 A2 ̅̅̅̅
2 ↑2 ̅̅̅̅
3 ↑3 A3 K0
Опишем основные элементы записи:
 Нi – начальный символ j-го алгоритма сценария деловой игры. Какиелибо
элементы
ЛСА,
записанные
перед
данным
символом,
исключены, так как это противоречит первому и второму условию
записи ЛСА;
 ↓k - нижняя стрелка k-го перехода. Является маркером перехода в
определенное место записи ЛСА;
 ↓k – верхняя стрелка k-го перехода. Является маркером перехода из
определенного места записи ЛСА;
 Аi – символ i-го оператора. В данном случае – Аi-ая сцена j-го
сценария деловой игры;
 ω – символ безусловного перехода;
 Рn – символ n-го условия перехода. Отвечает за переход по
следующей стрелке
 Kj – конечный символ j-го алгоритма сценария деловой игры.
Рассмотрим алгоритм работы ЛСА:
 считываем первый символ – H0. Данный символ отображает номер
загруженного сценария деловой игры. Переходим к следующему
элементу;
 считываем ↓2. Данный символ отображает место перехода в ЛСА.
Переходим к следующему элементу;
 считываем
A1.
Данный
символ
является
сценой
алгоритма.
Идентификатор данной сцены передается в регистр состояний. После
обработки,
в
регистр
состояний
14
из
операционной
модели
возвращается двоичный код. Считываем двоичный код из регистра
состояний и переходим к следующему элементу;
 считываем
Р1. Данный символ является условием перехода по
следующей за данным символом верхней стрелке перехода. Переход
осуществляется на основе анализа двоичного кода, считанного из
регистра состояний:
o если был считан символ 0 из регистра, происходит переход по
верхней стрелке ↑1 к символу нижней стрелки ↓1,после чего
происходит считывание следующего элемента – А3;
o если был считан символ 1 – перехода по стрелке ↑1 не
происходит;
 считываем ↓3. Пропускаем символ;
 считываем ↓1. Пропускаем символ;
 считываем А2. Передаем в регистр состояния для обработки. После
обработки
считываем
двоичный
код
из
регистра
состояния.
Переходим к следующему элементу;
 если для сцены А2 был считан код 10 или 11. Происходит обработка
кода – (1)0 первый элемент двоичного кода относится к символу
условия 2, а - 1(0) относится к символу условия 3:
o считываем 2. Данный символ является условием перехода,
однако отличается методом обработки двоичного кода:
o если был считан код 10 для сцены А2, то происходит переход
по стрелке ↑2 к стрелке ↓2. Ход алгоритма возвращается в место
чтения символа А1;
 если был считан код 01 для сцены А2, пропускается обработка
условия 2 и верхняя стрелка перехода ↑2. Считываем 3. При
отработке данного условия происходит переход по стрелке ↑3 к
стрелке ↓3;
 если был считан код 00 для сцены А2, пропускается обработка
условий 2 и 3 и считывается элемент А3. Происходит передача
кода сцены в регистр состояний, после обработки считывается код и
15
считывается следующий элемент. Так как следующий элемент – К0,
был достигнут конец сценария - работа с текущей ЛСА заканчивается.
Используя описанный алгоритм работы с ЛСА, а также учитывая основные
условия корректной записи логических схем алгоритмов, можно приступить к
программной реализации.
2.2 Загрузка сценария деловой игры
Началом работы студии будет запуск самой программы и выбор
интересующей деловой игры. Поскольку за взаимодействие программы и
пользователя отвечает операционная модель, выбор игры будет осуществляться на
уровне ОМ.
После выбора игры в автоматную модель поступает идентификатор
необходимого для загрузки сценария. Согласно данному идентификатору,
происходит поиск сценария в базе данных, загрузку сценария в память программы.
Данный подход позволит избежать утери данных, удаление сценария из базы
данных при непредвиденных завершениях программы.
Выделим основные функции на данном этапе:
 чтение идентификатора деловой игры;
 открытие базы данных;
 поиск сценария;
 загрузка сценария в память;
 закрытие соединения с базой данных.
Данные функции будут отвечать за загрузку ЛСА деловой игры из базы
данных. Диаграмма активности для загрузки сценария представлен ниже (рис. 2.1).
16
Чтение идентификатора
сценария
Инициализация подключения
к базе данных
Поиск в базе данных
сценариев ДИ
Сформировать сообщение об
ошибке
нет
ЛСА найдена
да
Загрузка ЛСА
Закрыть соединение с базой
данных
Рисунок 2.1 Диаграмма активности для загрузки сценария
На вход данной процедуры поступает идентификатор сценария. Процедура
активирует подключение к базе данных и подготавливает ее к поиску
интересующего сценария деловой игры. При отсутствии запрашиваемой деловой
игры, программа должна уведомить всю систему об ошибке, в противном случае –
приступить к проверке сценария игры на корректность.
Исходя из этого, входной информацией будет являться идентификатор
сценария, исходящей информацией будет являться ЛСА, либо сообщение об
ошибке, если таковая обнаружится.
При программной реализации для загрузки тестового сценария изначально
было использовано диалоговое окно ручного выбора деловой игры. Далее, загрузка
с помощью диалогового окна была заменена на модуль для работы с базой данных
деловых игр посредством выполнения sql-запросов. Данный способ позволяет в
17
автоматическом режиме загружать деловую игру и приступить к ее проверке на
корректность.
2.3 Проверка ЛСА на корректность
После загрузки ЛСА из базы данных следует проверить данный сценарий на
корректность. Данная процедура позволит избежать дальнейших ошибок при
работе студии.
Основными критериями для проверки корректности сценария будут являться
условия записи логических схем алгоритмов:
 строка начинается начальным оператором и конечным оператором;
 перед начальным и конечным оператором не должно быть стрелок
перехода к той или иной сцене;
 после каждого условия обязательно стоит верхняя стрелка перехода;
 для каждой верхней стрелки с номером i должна быть только одна
нижняя стрелка перехода с аналогичным номером.
Исходя из этого, следует разбить выполнение операции проверки сценария
на составляющие.
Первой проверкой будет являться наличие начального и конечного
операторов. Данная функция позволит пройти проверку на наличие начального и
конечного символов ЛСА – при отсутствии данных элементов в строке сценария
корректное выполнение загруженной деловой игры невозможно.
После проверки на наличие начального и конечного символов производится
проверка на наличие посторонних символов до начального элемента сценария и
после конечного элемента.
Далее следует проверка на наличие верхней стрелки после каждого условия.
В данную функцию также можно включить проверку на парность верхних и
нижних стрелок с одинаковым номером, а также проверку на единичность i-тых
нижних переходов. Проверка на единичность переходов является важным
моментом при проверке сценария на правильность – позволить избавиться от
конфликтов
при
переходе
от
i-ой
верхней
стрелке
к
i-той
нижней.
Кроме обозначенных функций, следует реализовать проверку на наличие верхней
стрелки между начальным символом и символом первой сцены. Наличие верхней
18
стрелки приводит к тому, что во время выполнения алгоритма игра не будет
попадать на первую сцену – этого следует избежать.
В результате, за проверку корректности ЛСА будут отвечать 2 функции:
 проверка начальных и конечных операторов;
 проверка парности верхних и нижних стрелок перехода.
Алгоритм проверки ЛСА на корректность представлен ниже. Алгоритм
проверки начальных и конечных операторов (рис. 2.2) и алгоритм проверки
парности верхних и нижних стрелок (рис. 2.3).
Проверка парности
верхних и нижних стрелок
перехода
Имеются ли
непарные стрелки
перехода
да
нет
После
каждого условия стоит
верхняя стрелка
перехода
Сформировать
сообщение об ошибке
Нет
да
да
Имеется ли более 1
нижней i-ой стрелки
Нет
Рисунок 2.2 Диаграмма активности алгоритма проверки начальных и конечных операторов
19
На данном этапе проверки корректности ЛСА происходит проверка на
наличие ошибки при поиске ЛСА, инициализация проверки ЛСА на корректность и
проверка начальных и конечных операторов. В данную проверку входит проверка
на наличие данных операторов, на наличие посторонних символов перед
начальным элементом и после конечного элемента.
Имеется ли на
входе ошибка
да
нет
Проверка начальных и
конечных операторов
Имеются ли начальный и
конечный операторы
нет
Сформировать
сообщение об ошибке
да
Завершить работу
системы
да
Имеются посторонние
символы перед начальным
элементом и после конечного
элемента
Удаление
ненужных
символов
Проверка парности
верхних и нижних стрелок
перехода
Рисунок 2.3 Диаграмма активности проверки парности верхних и нижних стрелок перехода
На этапе проверки парности верхних и нижних стрелок перехода происходит
проверка на наличие непарных стрелок, на проверку наличия верхней стрелки
после каждого условия перехода и проверка на наличие более одной нижней i-ой
20
стрелки перехода. Данные процедуры позволят избежать ошибок, которые могут
возникнуть во время работы студии с данным сценарием.
На данном этапе реализована еще одна функция, предназначенная для
упрощения работы алгоритма. Данная функция считает количество нижних
стрелок перехода и привязывает к ним следующую сцену. В результате
выполнения данной функции создается массив со сценами для каждой i-ой нижней
стрелки (рис. 2.4).
Считаем количество
нижних стрелок
да
Есть еще вхождения
нижних переходов
Нет
Создаем массив
переходов
Заполняем массив нижних
стрелок соответствующими
сценами
Рисунок 2.3 Диаграмма активности формирования массива сцен деловой игры
2.4 Передача кода сцены в регистр состояний
Следующей функцией автоматной модели будет являться передача кода
сцены в регистр состояний. При первом запуске деловой игры, после ее загрузки из
базы данных и проверки на корректность, следует переход на первую сцену.
Автоматная модель записывает код первой сцены в регистр состояний, где далее
21
операционная модель считывает этот код из регистра и взаимодействует с
пользователем.
После того, как от операционной модели был получен через регистр
состояний двоичный код результатов взаимодействия со сценой, автоматная
модель анализирует данный код, и в зависимости от результатов, переходит к той
или иной сцене. Далее, после перехода, происходит запись нового кода сцены в
регистр состояния.
Исходя из этого, выделяется всего одна функция, которая будет отвечать за
запись кодов сцен в регистр состояний (рис. 2.6).
Чтение символа
Пропускаем
символ
Символ
оператора Аi
да
Считываем
символ пока
число
нет
нет
Конечный
символ
Формирование кода
сцены
Формирование
сообщения
Передача кода
сцены в регистр
состояний
Изменение
состояния в регистре
состояния
Завершение
работы студии
Пока состояние регистра
равно “O”, создаем
бесконечный цикл
Рисунок 2.5 Диаграмма активности передачи кода сцены в регистр состояний
22
Для формирования кода сцены процедура считывает символы до тех пор,
пока не прочтет символ оператора A. Далее происходит процесс считывания числа
- идентификатора сцены А. Процесс происходит до тех пор, пока не будет прочтен
нечисловой символ. Сформированный А код сцены передается в регистр
состояний.
Для упрощения дальнейшей работы всего алгоритма, процесс считывания
для определенного элемента вынесен в отдельную процедуру. Данный шаг
позволит использовать ее для определения идентификатора любого элемента
сценария, будь это стрелка перехода или символ условия.
Пример выполнения процедуры:
Н ↓3 А23 ↑1 ↓2 К – текущая ЛСА. Процедура пропускает символы до тех
пор, пока не считает символ A. Далее формируется номер сцены – считываются
цифры после символа А до тех пор, пока не встретится нечисловой символ - ↑.
Поскольку взаимодействие
между автоматной
и
операционной
моделями
происходить путем передачи идентификатора сцены, в регистр состояния будет
записаны следующие данные – код текущей сцены 23 и состояние регистра будет
изменено с “А” на “О”.
По достижению конца ЛСА происходит передача конечного символа в
регистр состояния, сохраняются результаты работы в режиме отладчика.
2.5 Чтение и анализ двоичного кода из регистра состояния
Следующей функцией автоматной модели будет чтение двоичного кода из
регистра и его анализ.
Чтение и анализ следует объединить в одну функцию. Выделим ее основные
задачи:
 считать код из регистра;
 анализ и сравнение полученных результатов с условиями перехода к
следующей сцене;
 переход к следующей сцене.
Количество нулей и единиц в двоичном коде будет зависеть от количества
условий для каждой конкретной сцены. Сравнение полученных результатов будет
происходить с условиями для каждой сцены. Переход к следующей сцене будет
23
осуществлен только после сравнения всех условий с полученными данными – по
результатам сравнений по определенному условию будет произведен переход к
следующей сцене (рис. 2.5).
В данной процедуре происходит чтение двоичного кода из регистра
состояний. Далее происходит считывание символа двоичного кода и считывание
условия для текущей сцены. После идет проверка, чему равен прочтенный символ
двоичного кода – 0 или 1.
Далее считывается символ:
 символ условия - сравнивается прочтенное условие для текущей
сцены – прямое (Р) или обратное (Р) условие. В зависимости от
обработки условий совершается переход по верхней стрелке, которая в
ЛСА идет сразу после прочтенного условия перехода, либо
происходит пропуск символов до следующего условия;
 символ верхней/нижней стрелки – происходит пропуск символов пока
считывается верхняя/нижняя стрелка;
 символ безусловного перехода – происходит переход по верхней
стрелке;
 символ сцены – переход к стадии выделения оператора ЛСА.
24
Чтение двоичного кода
из регистра состояний
Считываем символ
двоичного кода
Пропускаем символы
пока считывается нижняя/
верхняя стрелка
Считываем символ
Символ
условия
нет
Символ верхней/
нижней стрелки
да
Пропускаем символы
пока считывается
нижняя/верхняя стрелка
Нет
да
нет
Считанный символ
двоичного кода равен
нулю?
нет
Считано обратное
условие (с чертой)
да
да
Считано обратное
условие (с чертой)
Нет
да
Переходим по
верхней стрелке
Символ
безусловного
перехода
да
Выделение
оператора ЛСА
нет
Рисунок 2.6 Диаграмма активности чтения и анализа двоичного кода
25
При возникновении каких-либо ошибок во время выполнения модулем своих
функций будут формироваться сообщения для оповещения пользователя об
ошибке. Кроме того, для предотвращения возникновения ошибок в будущем,
сообщения об ошибках будут сохраняться в специальный файл, куда будут
записываться
все
сообщения,
содержащие
данные
об
ошибке,
условиях
возникновения данной проблемы и идентификатора сценария для ее дальнейшей
ликвидации разработчиками.
Исходя из описанных алгоритмов выполнения основных функций модуля,
было разработано техническое задание. Оно включает основные аспекты,
касательно будущей разработки автоматной модели. Техническое задание
размещено в разделе «Приложение».
2.6 Программная реализация
Приступая к разработке модуля автоматной модели, было решено
спроектировать диалоговое окно, которое в дальнейшем будет использоваться, как
окно отладки в главной части студии. Окно отладки представляет собой форму, на
которой размещены области отображения информации о текущей стадии работы
студии, текущих задействованных данных и основные кнопки для работы в режиме
отладки (рис. 2.7).
Рисунок 2.7 Окно предварительной отладки модуля автоматной модели
26
На начальном этапе программирования загрузка тестового сценария ЛСА
происходит вручную. При нажатии на кнопку «Загрузка» происходит открытие
диалогового окна, где вручную выбирается тестовый пример, после чего
происходит его чтение и запись в память программы. После записи в память
программы происходит перевод всей загруженной строки в нижний регистр, после
чего вызывается функция проверки загруженного сценария. При «слиянии»
операционной
и
автоматной
моделей,
функция
загрузки
переведена
в
автоматический режим – в операционной модели будет вызываться процедура
загрузки сценария с параметром. В качестве параметра будет передаваться
название деловой игры, по которому, посредством SQL-запроса, будет получен
путь к файлу с необходимой деловой игрой. После успешной загрузки сценария в
режиме отладки будет отображена информация об успешном выполнении загрузки
ЛСА (рис. 2.8).
Рисунок 2.8 Загрузка сценария деловой игры.
2.7 Алгоритм работы автоматной модели
Следующим шагом выполнения работы автоматной модели будет проверка
сценария на наличие ошибок. Первым этапом проверки будет проверка на наличие
начальных и конечных символов. Данная проверка происходит путем нахождения
индекса вхождения начального и конечного символов в загруженную строку
27
сценария – если какой-либо индекс вхождения равен -1, программа отображает
сообщение об ошибке в загруженном сценарии и поменяет переменную “errors” с
false на true. Данный флаг отвечает за наличие каких-либо ошибок в загруженной
ЛСА. Основной алгоритм выполнения работы с ЛСА будет исполняться только
лишь в том случае, если значение переменной “errors” будет иметь значение false,
что свидетельствует об отсутствии каких-либо ошибок в ЛСА.
После проверки на наличие начального и конечного символов происходит
проверка на посторонние символы перед начальным и после конечного символов.
Если какие-либо символы будут обнаружены – они будут «обрезаны» из
загруженной ЛСА.
Следующим шагом проверки будет являться проверка на парность верхних и
нижних переходов. Данная проверка состоит из следующих шагов:
 поиск i-го верхнего перехода;
 поиск i-го нижнего перехода;
 сверка первого и последнего вхождения i-го перехода.
Поиск верхних и нижних переходов позволяет проверить, имеются ли
одиночные нижние или верхние переходы. Наличие одиночных переходов не
позволит корректно выполнять работу с загруженной ЛСА. При обнаружении
одиночных переходов программа меняет значение переменной “errors” на true и
останавливает алгоритм проверки сценария. Если все найденные верхние и нижние
стрелки имеют свою пару, производится проверка на наличие двух i-ых нижних
переходов – при их обнаружении дальнейшее корректное выполнение работы с
загруженным сценарием невозможно. В этом случае программа меняет значение
переменной “errors” на true и также останавливает выполнение алгоритма проверки
ЛСА. При успешном выполнении проверки на парность верхних и нижних стрелок
перехода программа отображает найденные верхние и нижние переходы в окне
отладки в режиме отладчика (рис. 2.9).
28
Рисунок 2.9 Проверка на парность верхних и нижних стрелок перехода
Следующим этапом проверки сценария будет
наличие верхней стрелки
между начальным символом и символом первой сцены сценария. Наличие данного
перехода приводит к тому, что во время выполнения алгоритма, программа не
сможет попасть на самую первую сцену. При обнаружении данного верхнего
перехода программа меняет значение переменной “errors” на true и также
останавливает выполнение алгоритма проверки.
Если при выполнении процедур проверки сценария не было обнаружено
никаких ошибок, процедура проверки всей ЛСА прошла успешно. Однако, для
упрощения дальнейшей работы основной процедуры автоматной модели, был
добавлен процесс формирования связи нижних переходов и соответствующих им
сцен. Создается массив связей.
Н ↓3 А23 ↑1 ↓2 К – для нижней стрелки с индексом 3 соответствующая ей
сцена А23. Данный подход позволит быстро находить необходимую сцену при
переходе по определенной верхней стрелке. Данный алгоритм считает общее
количество нижних переходов. После того, как было подсчитано количество
переходов, происходит повторный проход по строке сценария, где для каждой
нижней i-ой стрелки ищется соответствующая ей сцена. Для этого ищут последнее
вхождение нижней стрелки в строку сценария. Далее формируется подстрока,
начиная с последнего вхождения нижней стрелки и до конца строки сценария. В
29
сформированной строке происходит поиск первого вхождения символа сцены «А».
Как только был найден элемент, происходит его запись в массив. Результат
выполнения всей проверки и данной функции представлен ниже (рис. 2.10).
Рисунок 2.10 Выполнение проверки сценария и формирование массива переходов
На этом этапе проверка сценария окончена – происходит переход к
выполнению основной функции автоматной модели.
Первым делом происходит чтение первого элемента – h, который заносится в
переменную currscene. Далее происходит проверка значений currscene с ранее
обозначенными значениями. Данная проверка будет осуществляться с помощью
оператора switch(currscene), сравнивая его с меткой case. Ниже описаны константы
для каждой case-метки:
 case "h": начальный символ. Пропускаем его, считываем следующий
символ;
 case "a": если текущий символ равен символу сцены, происходит его
обработка;
 case "p": если текущая сцена равна сцене условия, то происходит его
обработка;
 case "u": если текущая сцена равна символу верхней стрелки,
происходит переход от i-ой верхней стрелки к i-той нижней стрелке;
30
 case "d": если текущая сцена равна символу нижней стрелки,
пропускаем ее – считываем следующий элемент;
 case "n": если текущая сцена равна сцене обратного условия, то
происходит его обработка;
 case "w": если текущая сцена равна символу безусловного перехода,
происходит переход к нижней i-той стрелке i-го безусловного
перехода;
 case "k": если текущая сцена равна конечному символу, работа
алгоритма заканчивается;
Ниже подробно описана обработка каждого из идентификаторов. Начальный
символ сценария не несет особой смысловой нагрузки на ход выполнения
алгоритма - данный символ пропускается.
Считанный символ, равный символу сцены, играет одну из важных ролей в
выполнении алгоритма деловой игры. После прочтения символа сцены происходит
формирование идентификатора для данной сцены. После чего происходит передача
сформированного идентификатора в регистр состояний, изменение значения
состояния регистра на “O” и запуск бесконечного цикла, выйти из которого можно
лишь в том случае, когда значение состояния регистра изменится на “A” – это
означает, что автоматная модель может приступить к работе. После выхода из
бесконечного символа происходит считывание бинарного кода из регистра
состояния. Далее происходит обработка двоичного кода и сравнение каждого
элемента с условиями для каждой сцены. Считывается следующий элемент строки
ЛСА и записывается в переменную currscene и сравнивается с первым элементом
двоичного кода. Разберем работу алгоритма на примере.
A1 P1 ↑1 N2 ↑2 ↓3 ↓4 – текущий обрабатываемый отрезок ЛСА. Считанный
из регистра состояния двоичный код равен 01.
Считывается текущая сцена и записывается в переменную currscene = “P”.
Считанный двоичный код равен 01. Считывается первый элемент двоичного кода –
0. Так как текущая сцена currscene = “P”, а первый элемент двоичного кода 0, то
происходит переход по следующей за “P” стрелкой ↑1.
31
Рассмотрим другой случай – считанный двоичный код равен 11. Текущая
сцена currscene = ”P”. Считываем первый элемент двоичного кода – 1. Так как
первый элемент двоичного кода равен 1, то перехода не происходит – считываем
следующее условие и заносим его в переменную currscene = “N”. Переход по сцене,
равной “N” происходит, если текущий считанный двоичный код равен 1, и не
происходит, если считанный двоичный код равен 0.
В зависимости от двоичного кода и следующих за текущей активной сценой
условиях происходит переход по той или иной ветке алгоритма. В конечном итоге,
работа происходит до тех пор, пока считанный символ не будет равен конечному.
Если текущий считанный элемент равен верхней i-ой стрелке перехода (u),
происходит поиск i-ой нижней стрелки (d) в массиве связей и по индексу i-1 из
массива переходов считывается элемент и записывается в переменную currscene.
Если текущий символ равен элементу нижней стрелки, происходит пропуск
данного символа и считывание следующего за ним элемента.
Текущий символ, равный символу безусловного перехода, обрабатывается
аналогично обработке символа i-го верхнего перехода – ищется i-ая нижняя
стрелка, далее из массива по индексу i-1 происходит запись новой сцены в
переменную currscene.
При достижении конца сценария автоматная модель передает в регистр
состояния значение переменной, обозначающей конец сценария. После записи
информации в регистр, происходит выход из цикла выполнения работы с деловой
игрой.
2.8 Интеграция автоматной и операционной моделей
Интеграция
автоматной
и
операционной
модели
осуществлена
на
программном уровне путем использования регистра состояний. Данный регистр
состояний отвечает за хранение информации, получаемой от каждой из моделей.
Регистр состояния использует следующие поля:
 id_scene – переменная, предназначенная для хранения идентификатора
сцены, получаемого из автоматной модели;
 code_of_action - переменная, предназначенная для записи бинарного
кода из операционной модели;
32
 active_model – переменная-сигнал, отвечающая за очередность
функционирования операционной и автоматной моделей.
Алгоритма загрузки сценария в автоматную модель выполняется при
нажатии на кнопку с интересующей деловой игрой. Далее, во время выполнения
процедуры mainfunc, при обработке сцены, идентификатор данной сцены
записывается в переменную id_scene, значение переменной active_model меняется
на “O”, и далее запускается выполнение цикла while (register.Arr[3] == "O"), где
происходит обращение к требуемой форме. После совершения пользователем
манипуляций с текущей сценой, значение переменной active_model программно
меняется с “O” на “A”, что означает, что функционирование переходит к
автоматной модели.
2.9 Основные функции режима отладки
Режим отладки служит для пошагового отображения работы автоматной
модели в целом. Основными функциями режима отладки являются пошаговая
обработка текущего символа сценария, и сохранение отредактированного сценария
в файл. Текущее состояние регистра состояния деловой игры будет также
отображаться в окне режима отладки.
Пошаговая обработка текущего символа будет происходить по аналогичному
алгоритму, применяемому в автоматическом режиме (рис. 2.11).
33
Сверяем текущий
символ (ТС)
Текущий символ
= символу сцены
Да
нет
Выделение текущего
идентификатора сцены
ТС =
символ верхнего
перехода
Нет
Запись идентификатора
в регистр состояния
ТС
=
Символ
безусловного
перехода
Считываем
двоичный код
Да
Да
Переход от i-ой верхней
стрелки к i-ой нижней
стрелке
Нет
ТС =
Нижней стрелке
Обрабатываем
двоичный код
нет
Формирование
нового ТС
Переход к следующей
за нижней i-ой стрелкой
сцене
Да
Пропускаем
символ
ТС= конечному символу.
Прекращаем работу
студии
Формирование
нового ТС
Рисунок 2.11 Диаграмма активности режима отладки
Единственное различие будет заключаться в следующем – обработка
текущего символа будет происходить не в цикле, а только по нажатию кнопки
перехода к следующей сцене. Данный подход позволит проверить корректность
отображаемых данных.
Описанные подходы к реализации функций автоматной модели позволяют
перейти от стадии проектирования к стадии реализации программного модуля. В
результате реализации программного модуля автоматной модели, а также
интеграции с операционной моделью, будет создан прототип подсистемы
проведения деловых игр для СКДИ.
34
Заключение
Основываясь на результатах анализа предметной области, можно сделать
вывод
о
том,
что
разработка
инструментария,
позволяющего
развивать
профессиональные компетенции в процессе обучения, является актуальной
задачей.
В процессе работы над
программным модулем были проанализированы
способы представления сценарии деловой игры и выбран способ представления в
виде логической схемы алгоритма из-за возможности хранения такого сценария в
базе данных СКДИ в виде текстовой строки. Также были рассмотрены различные
модели автоматов, которые, в основном, реализуют на графическое или матричное
представление логики выполнения.
Разработан алгоритм выполняющий интерпретацию ЛСА, содержащей
сценарий деловой игры и передающий в операционную модель код сцены, а также
алгоритм анализа двоичного кода, полученного из регистра состояния. Данный
анализ позволяет проходить по загруженному сценарию деловой игры.
Была
произведена
операционной
модели.
интеграция
Для
этого
разработанного
была
модуля
произведена
с
настройка
модулем
работы
операционной и автоматной модулей. Отдельно было произведено тестирование
основных функций автоматной модели.
Результатом
выпускной
квалификационной
работы
будет
прототип
подсистемы проведения СКДИ. Дальнейшие доработки данной подсистемы
позволят приблизиться к реализации проекта студии компетентностных деловых
игр.
35
Библиографический список
1) Викентьева, О.Л. Концепция студии компетентностных деловых
игр / О.Л. Викентьева,
А.И.
Дерябин,
Л.В.
Шестакова
//
Современные проблемы науки и образования. – 2013. – №
2.- [Электронный ресурс].- [Режим доступа: http://www.scienceeducation.ru/108-8746]. [Проверено: 03.04.2013].
2) Российская государственная библиотека / Центр информ.
технологий РГБ ; ред. Власенко Т.В. ; [Электронный ресурс].доступа:
[Режим
http://www.ispl.ru/Analiz_vozmozhnostey_geimerizaciii_4.html].[Проверено: 7.11.2013]
3) Крюков, К.В. О понятии формальной компетентности научных
сотрудников / К.В. Крюков, О.П. Кузнецов, В.С. Суховеров //
OSTIS-2013: Материалы III международной научно-технической
конференции. – Минск : БГУИР, 2013. – С. 143-146.
4) Бермус
А.Г.
Проблемы
и
перспективы
реализации
компетентностного подхода в образовании, Интернет-журнал
«Эйдос»
[Электронный
ресурс].-
http://www.eidos.ru/journal/2005/0910-12.htm].-
[Режим
доступа:
[Проверено:
8.12.2013]
5) Л.Точилов. Анализ возможностей геймеризации для подготовки
и развития кадров и знаний в ракетно-космической отрасли.
Предприятие
реального
времени.- [Электронный
ресурс].доступа:
[Режим
http://www.ispl.ru/Analiz_vozmozhnostey_geimerizaciii_1.html]
.-
[Проверено: 8.11.2013]
6) Деловые
игры
[электронный
ресурс].-
[Режим
доступа:
http://psyfactor.org/personal5.htm ].- [Проверено: 7.11.2013]
36
7) Левин В.И. Динамика логических устройств и систем. – М.:
Энергия, 1980.
8) Лекция 3: Способы описания работы дискретных устройств. НОУ
Интуит | Лекция | Способы описания работы дискретных
устройств.
–
[Электронный
ресурс].
–
[Режим
доступа:
http://www.intuit.ru/studies/courses/1031/242/lecture/6230?page=3#s
ect5].-[Проверено:24.04.2014]
37
38
Скачать