Компетентностная деловая игра - Программирование, компьютеры и кибернетика дипломная работа

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


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
В рамках данной работы была выполнена работа по проектированию и разработке прототипа подсистемы проведения деловой игры (ППДИ) студии компетентностных деловых игр (СКДИ). СКДИ является инструментальной средой для проектирования и проведения деловых игр [1, 2, 9, 10, 11]. В рамках СКДИ была разработана модель проведения деловой игры [9], которую необходимо реализовать в виде программного продукта. Была спроектирована архитектура ППДИ и разработан ее прототип. Также был спроектирован и разработан прототип модуля ППДИ - «Активный ресурс» (АР) [12, 13], который выступает в роли исполнителя и выполняет действия, заложенные в его сценарий.
1. Анализ существующих на данный момент алгоритмов для проектирования и проведения ДИ в студии компетентностных деловых игр.
2. Анализ алгоритмов и подходов к управлению временем, реализующих распределенное имитационное моделирование.
3. Формулировка требований к подсистеме проведения ДИ.
4. Разработка алгоритмов работы ППДИ.
5. Проектирование ППДИ с использованием диаграмм.
6. Проектирование моделей бизнес-процессов для построения сценария, выполняющегося ППДИ и разработка контрольного примера.
7. Проектирование ЛСА, реализующей сценарий ДИ, с учетом исполнения соответствующего БП во времени.
8. Проектирование базы данных (БД) подсистемы проведения ДИ.
11. Тестирование ППДИ с использованием разработанного контрольного примера.
Для выполнения данных задач были использованы следующие методы: метод функционального моделирования, объектно-ориентированное проектирование, объектно-ориентированное программирование, имитационное моделирование.
Практическая значимость работы заключается в модификации процесса проведения деловой игры. Разрабатываемая система будет учитывать порядок выполнения операций бизнес-процессов во времени, что позволит приблизить моделируемые процессы в ППДИ к реальным и поможет при дальнейшей доработке студии компетентностных деловых игр.
Результатом работы является прототип ППДИ, который позволяет провести деловую игру с учетом времени выполнения операций.
В самом начале работы требуется проанализировать область, представляющую интерес в текущей работе. В данной главе описана общая структура студии компетентностных деловых игр, в частности подсистемы проведения, а также выполнен обзор алгоритмов распределенного имитационного моделирования.
Компетентностная деловая игра - это информационная система, целью которой является получение определенного уровня профессиональных компетенций в процессе реализации сценариев, определяемых моделями бизнес-процессов предметной области. Студия компетентностных деловых игр выступает инструментарием для разработки и проведения таких деловых игр. Сотрудниками кафедры информационных технологий в бизнесе, в рамках которой разрабатывается СКДИ, был предложен многомодельный подход к разработке такой инструментальной среды [2]. Структурная схема СКДИ представлена на рисунке 1.1.
Рисунок 1.1. Структурная схема СКДИ
В рамках данной работы будут рассмотрены подсистемы проектирования и проведения. Подсистема проектирования ориентирована на разработку сценариев деловых игр, моделей предметных областей, на базе которых выполняются сценарии, также с помощью подсистемы проектирования могут создаваться учебно-методические материалы для проведения игр и контрольно-измерительные материалы. Исходные данные для подсистемы проектирования представляет модель предприятия в неформализованном виде [2].
После проектирования деловой игры формализованная модель данных должна быть наполнена самими данными, что производится в рамках подсистемы проведения [14]. В подсистеме проведения происходит выполнение сценария деловой игры и создается деловая обстановка, в которой игрок принимает решения, тем самым формируя определенный набор компетенций. Деловая обстановка представляет собой совокупность различных ресурсов, доступных для игрока. При проведении деловой игры игрок выбирает различные ресурсы, после чего происходит выполнение определенной операции бизнес-процесса. Дальше система предлагает игроку доступные для выполнения очередной операции БП ресурсы.
Некоторые существующие в игре ресурсы могут играть активную роль (оппонент или активный ресурс), работа которых осуществляется в отдельном модуле. Модуль «Активный ресурс» выступает в роли исполнителя, т.е. исполнителем может быть не только игрок, поскольку существуют такие действия, которые происходят в результате совершения каких-либо других действий. АР выполняет операцию как отдельный участник на основе существующих данных либо запрашивая дополнительную информацию у игрока [12].
Как подсистема проведения ДИ, так и модуль «Активный ресурс» предполагает наличие автоматной и операционной моделей (АМ, ОМ). В АМ происходит выполнение алгоритма, заложенного в сценарий ДИ. В качестве такой модели используется полученная на этапе проектирования логическая схема алгоритма. В ОМ формируется деловая обстановка на основе команды, поступающей из АМ. ОМ представляет собой множество наборов, включающих модель экрана, модель сцены и модель ресурсов (или Ресурсы) [13].
Алгоритм выполнения операции, включающий определенные в [12] функции АМ и ОМ, следующий:
2.1. ОМ формирует условие, отвечающего действиям пользователя, для перехода к следующей сцене.
2.3. АМ принимает условие, выполняет запрос к БД.
3. ОМ получает команду, выполняет запрос к БД, ищет модель сцены.
4. ОМ выбирает из БД ресурсы, соответствующие текущей модели сцены.
5. ОМ загружает ресурсы в модель экрана (выводит на экран).
Также в работе [12] были определены функции, выполняемые активным ресурсом:
2. Выделение команды из ЛСА (выполняется автоматной моделью).
3. Выбор модели сцены и ресурсов (диалоговых окон) по команде (выполняется ОМ).
4. Вывод на экран с помощью МЭ ресурсов из БД, соответствующих модели сцены (выполняется ОМ).
5. Получение ответов игрока (выполняется ОМ).
Однако в системе нельзя задать время выполнения операций и смоделировать выполнение операций во времени, т.е. все операции выполняются в логическом порядке (согласно ЛСА), но без учета времени. В рамках данной работы предполагается применить распределенную имитационную модель к существующим алгоритмам в СКДИ, что поможет приблизить деловую обстановку в игре к реальной.
1.2 Анализ моделей бизнес-процессов СКДИ
Чтобы применить распределенную имитационную модель в СКДИ, необходимо проанализировать разработанные в рамках СКДИ алгоритмы, а именно языки моделей бизнес-процессов, которые не отображают временные характеристики БП на данный момент. В СКДИ используются понятия трех моделей бизнес-процессов: реального (существующего на предприятии), унифицированного (промежуточного между реальным и учебным) и учебного унифицированного (на котором можно обучать). В рабочем (или реальном) бизнес-процессе (РБП) имеются определенные действия, их исполнители и различные ресурсы, необходимые для осуществления действий и получаемые в результате реализации действий. Пример диаграммы IDEF0 для абстрактного РБП (см. рис. 1.2):
Рисунок 1. 2 . Пример диаграммы IDEF 0 для РБП
Здесь D1...D4 - это действия (или операции), осуществляемые в бизнес-процессе, R1…R6 - ресурсы на входе и выходе действий, U1, U2, U3 - управление действиями, I1, I2 - исполнители действий, M1, M2 - механизмы (табл. 1.1).
Таблица 1. 1. Описание диаграммы IDEF0
Выполняемые на предприятиях реальные бизнес-процессы не могут использоваться как модели при проектировании деловых игр, поскольку они сложны, могут содержать ошибки при неправильной организации работы предприятия, к тому же решающие одну задачу БП на однотипных предприятиях могут отличаться. Ввиду наличия таких фактов вводится понятие модели унифицированного бизнес-процесса (УБП), в котором будут отражены существенные независимые характеристики реальных бизнес-процессов предприятий [2].
Модель УБП состоит из двух частей «Последовательность операций» и «Операция». «Последовательность операций» представляет собой строгий алгоритм выполнения операций, который можно представить в виде блок_схем. Для построения такой модели необходимо выделить операции исполнителя. «Операция» - это модель, которая описывает каждый элемент УБП детально.
Рисунок 1.3. Блок-схема основной программы
Рисунок 1.4. Модель операции для операции 1
На основе УБП строится модель учебного унифицированного бизнес-процесса, которая представляет собой модель карты операций - дерева, состоящего из множества операций и множество точек принятия решений (ТПР). ТПР позволяет перейти от одной операции к другой, причем из одной точки можно перейти к нескольким операциям (рис. 1.5). Таким образом, получается иерархическая структура, каждая ветвь которой это возможный путь в ДИ [11].
Как видно из этих моделей, языки не отражают время операций, в связи с чем требуется изменение языков данных моделей с учетом времени. Для добавления времени в модели БП было решено использовать алгоритмы распределенного имитационного моделирования.
1.3 Обзор имитационного моделирования
В имитационном моделировании выделяют три вида времени: физическое, модельное и процессорное. Физическое время характеризует процессы в реальной системе; модельное время отображает физическое время в виртуальное, использующееся имитационной системой. В зависимости от требований к процессу это время может идти как быстрее физического, так и медленнее. Процессорное время - это фактическое время выполнения модели на компьютере [15].
На данный момент существует два направления решения проблемы управления временем в имитационном моделировании - это последовательное и распределенное ИМ [16, 17]. В последовательном ИМ все три понятия времени соотносятся между собой однозначно, что касается распределенного моделирования, то процесс протекания времени является более сложным из-за возникающих парадоксов времени [15]. Ниже, в таблице 1.2, представлен сравнительный анализ последовательного и распределенного ИМ:
Таблица 1.2 . Сравнительный анализ последовательного и распределенного ИМ
Централизованный (в управляющей программе)
Глобальные (в управляющей программе)
Программа синхронизации компонентов моделирования
Взаимодействие программы синхронизации с компонентами моделирования
Взаимодействие управляющей программы с объектами посредством клиент-серверного подхода
Взаимодействие логических процессов с коммуникационной системой с помощью интерфейса
Взаимодействие между компонентами моделирования
Обмен сообщениями между логическими процессами
Сложно (т.к. необходима синхронизация между логическими процессами)
Выше при моделировании несложных систем
Зависит от алгоритма синхронизации модельного времени
Развитие распределенного ИМ осуществляется по двум направлениям: параллельное дискретное событийно-ориентированное моделирование PDES (Parallel Discrete Event Simulation) и объединение разнородных систем моделирования.
В первом случае имитационная модель представляет собой совокупность логических процессов, которые обмениваются сообщениями друг с другом. ЛП распределяются по вычислительным узлам вычислительной системы и обмениваются сообщениями, используя линии связи между ее узлами. Однако при переносе системы на другую платформу могут возникнуть проблемы, т.к. имитационные модели тесно связаны со средой, для которой они разрабатывались [18, 19].
Второе направление (ИМ высокого уровня) описывает программные средства, которые позволяют объединить уже готовые системы имитации для проведения распределённого имитационного эксперимента. Задача состоит в том, чтобы создать окружение для взаимодействия уже ранее созданных имитационных моделей. В настоящее время широко используется такой подход как HLA (High Level Architecture или «Архитектура высокого уровня») [16, 18, 19], который в [16] описан как новый этап развития ИМ.
В таком имитационном моделировании его компонентами являются не объекты как в последовательном ИМ, не логические процессы как в параллельном или распределенном ИМ, а «федераты», которые объединяются в «федерации». Федераты одной федерации могут быть разнородными (это могут быть имитационные модели, тренажеры, программа для сбора данных и т.д.). Взаимодействие федератов и их исполнение в едином модельном времени происходит с помощью структур данных, которые поддерживают сервисы RTI (RunTime Infrastructure) [16, 19]. RTI - компонент, представляющий собой операционную систему, которая обеспечивает обмен данными между федерациями и федератами.
Далее работа будет сосредоточена на распределенном ИМ.
При распределенном имитационном моделировании первичной единицей является логический процесс - последовательная подмодель, структура которой выглядит как структура последовательной имитационной модели (рис. 1.6).
Рисунок 1.6 . Схема выполнения логического процесса
Каждый ЛП имеет собственный локальный список событий, собственные часы локального модельного времени и собственную управляющую программу (УП). Задача УП - продвижение модели из одного состояния модели в другое, т.е. работа УП состоит в том, чтобы из списка необработанных событий найти событие с минимальной меткой времени и обработать его. Управляющую программу в последовательном ИМ называют симулятором; в распределенном ИМ - алгоритм синхронизации, который предназначен для синхронизации компонентов моделирования (логических процессов) [19].
Логические процессы взаимодействуют исключительно с помощью передачи сообщений. Получив сообщение, которое имеет форму события, логический процесс добавляет это событие (в соответствии со временем) в упорядоченный список своих локальных событий. После чего УП выполняет измененный список событий, т.е. логика выполнения логического процесса-получателя меняется. На рисунке 1.7 изображена схема выполнения распределенной модели, включающая коммуникационную подсистему как отдельный компонент, который синхронизирует модельное время для всех логических процессов. Взаимодействие каждого ЛП с ней осуществляется с помощью некоего коммуникационного интерфейса (КИ) [16, 17].
Хронологический порядок выполнения событий должен отслеживаться алгоритмом управления временем. Если временная метка одного события меньше временной метки другого события, значит, сначала должно быть обработано первое событие, затем второе. Может возникнуть момент, когда второе событие произошло раньше или во время выполнения первого события, а должно было наступить только после окончания первого события. Такая ситуация называется парадоксом времени.
Для исключения возможности появления парадоксов времени в системе распределенного моделирования должна быть реализована специальная программа синхронизации, которая будет входить в состав коммуникационной подсистемы. Такая программа синхронизации (или алгоритм синхронизации) реализует некий алгоритм «синхронизации модельного времени».
Рисунок 1. 7 . Схема выполнения распределенной модели , КИ - коммуникационный интерфейс, УП - управляющая программа, ПМ - подмодель, ЛП 1... N - логически е процесс ы
Если все логические процессы одновременно достигнут некоторого заданного значения модельного времени или в модели не останется будущих событий, моделирование завершается [16].
Существует два класса алгоритмов управления временем: консервативный и оптимистический. Цель этих алгоритмов состоит в том, чтобы сохранить причинно-следственную связь логических процессов, т.е. все процессы должны быть выполнены в неубывающем порядке их временных меток. Консервативный и оптимистический подходы могут быть реализованы с помощью различных механизмов [15-25], которые имеют как преимущества, так и недостатки.
Консервативный подход позволяет избежать всех возможных ошибок причинности. Основная идея консервативных алгоритмов состоит в предотвращении парадоксов времени, т.е. необходимо определить время, когда обработка очередного события из списка необработанных событий будет «безопасной». Событие называют безопасным, если можно гарантировать, что логический процесс в дальнейшем не получит от других логических процессов сообщение с меньшей временной меткой. Консервативный подход не позволяет обрабатывать событие до тех пор, пока не убедится в его безопасности.
Консервативный алгоритм Chandy, Misra и Bryant'а [20, 21] - один из первых консервативных алгоритмов. Реализация алгоритма простая, алгоритм имеет простое управление и структуру данных. Однако механизм синхронизации блокирует процессор и, как следствие, становится подвержен к тупиковым ситуациям. Выходные сообщения, время которых не возрастает монотонно (события со временем задержки), не могут быть легко обработаны. Способ решения данной проблемы - создать сообщение самому себе, указав, что выходное значение будет сгенерировано после задержки [22, 23].
Следующий предложенный Chandy и Misra консервативный алгоритм позволяет избавиться от проблемы с возникновением тупиков, передавая «пустое» или «нулевое» сообщение [24]. Этот алгоритм используется, чтобы объявить об отсутствии реального сообщения, и является дополнительной информацией для определения очередного безопасного события. Тогда некоторый ЛП 2 , получив такое сообщение от ЛП 1 , «понимает», что ЛП 1 не пришлет сообщение с меньшей временной меткой. Основным недостатком данного алгоритма является большое количество пустых сообщений в случае, если логическому процессу, получившему нулевое сообщение, необходимо отправить вторичные нулевые сообщения с той же меткой времени другим логическим процессам, чтобы сообщить об отсутствии реального сообщения.
В следующих консервативных алгоритмах предполагается усовершенствование последнего алгоритма. К примеру, предлагается отправлять пустое сообщение не всегда, а только по специальному запросу для того, чтобы уменьшить количество нулевых сообщений. Приостановленный логический процесс отправляет запрос всем логическим процессам, сможет ли он выполнить событие с минимальной временной меткой, находящейся за пределами минимальной временной отметки (временного горизонта) [16]. Или же необходимо, чтобы все логические процессы уже владели информацией о значении временной метки следующего необработанного события для того, чтобы вычислить временный горизонт будущих событий процесса.
Также для консервативных алгоритмов синхронизации характерной особенностью является использование предварительного просмотра (lookahead). Величина предварительного просмотра указывает на то, что на протяжении некоторого временного отрезка исходящих сообщений не будет [17].
Что касается оптимистических алгоритмов, то их реализация не предполагает строгого соблюдения ограничений причинно-следственной связи. При выполнении алгоритма оптимистического подхода в распределенном ИМ полагают, что парадоксы времени не возникнут во время параллельного исполнения логических процессов [16]. Если же парадокс времени возник, оптимистические алгоритмы выполняют откат логического процесса до последнего корректного состояния системы для восстановления правильного порядка. Откат включает в себя устранение последствий некорректного исполнения логического процесса и повторное исполнение этого процесса, учитывая сообщение, которое вызвало парадокс времени [16, 25].
Из рассмотренных выше алгоритмов можно сделать следующий вывод: все алгоритмы стараются поддерживать хронологический порядок событий, т.е. суть алгоритма заключается, во-первых, в обеспечении логического порядка наступления событий; во-вторых, в не нарушении временного фактора наступления событий. В СКДИ за логику выполнения отвечает ЛСА, в которой содержатся условия, переходы и осуществляемые операции, необходимо только, чтобы эти операции осуществлялись в соответствии со временем. Для этого были рассмотрены подходы продвижения времени в распределенном ИМ.
Распределенная модель, как было сказано выше, - это модель, состоящая из нескольких последовательных подмоделей, называемых логическими процессами, и одной коммуникационной подсистемы, которая реализует синхронизацию логических процессов. Логический процесс содержит собственные часы локального времени. После анализа алгоритмов распределенного ИМ следующим шагом было решено рассмотреть подходы к продвижению времени, используемые в имитационных системах. Существует три основных алгоритма управления временем:
1. Моделирование с фиксированным шагом.
2. Моделирование, управляемое событиями.
3. Моделирование, управляемое часами реального времени.
При реализации продвижения времени в системе первым способом состояние системы не зависит от наступления события, изменение состояния системы происходит через фиксированные промежутки времени [16, 19]. В каждый такт времени происходит проверка наличия запланированных событий в течение предыдущего интервала времени. Если на интервал были запланированы события, то считается, что эти события происходят в конце этого интервала (рис. 1.8). Проверка также выполняется, если на данный временной интервал событий запланировано не было. Если на проверяемый интервал запланированы два события с разным временем наступления, считается, что оба этих события произошли в конце интервала. Реальное событие можно «привязать» как к концу такта (его правой границе), так и к его началу (левой границе), что зависит от предпочтений или заданных условий [26]. Подход достаточно простой, но присутствует проблема, связанная с определением величины шага [19].
Второй способ предполагает случайный (или особый) шаг продвижения времени, который определяется наступлением событий. В качестве следующего значения часов модельного времени может выбираться событие с минимальной временной меткой. Если же известен закон распределения интервалов между событиями, шаг может определяться с помощью соответствующего датчика. Также при таком подходе могут наличествовать события, для выполнения которых в каждый квант времени необходимо вычислять логические условия, и, если такое условие истинно, событие выполняется.
Моделирование, управляемое часами реального времени, определяется синхронизацией модельного времени с процессорным, однако чаще здесь управление временем в системе зависит от скорости происходящих событий в реальном времени [16, 19].
Рисунок 1.8 . Механизмы продвижения модельного времени , E 1-7 - события
На рисунке представлены первые два подхода продвижения модельного времени, в некоторых источниках называемые «принцип дt» и «принцип дz», соответственно [26]. При моделировании с фиксированным промежутком времени в данном случае наступление событий приходится на конец такта. На рисунке показано как соотносится время с событиями. Как было сказано выше, дt - фиксированный, а дz - особый промежуток времени.
Изучив алгоритмы, а также подходы к реализации времени в распределенном ИМ, можно спроецировать имитационную модель на подсистему проведения ДИ.
1.4 Связь распределенного имитационного моделирования с ППДИ
Выполнение любых действий, требующих реакции, в подсистеме проведения деловых игр производится с помощью модуля «Активный ресурс», который должен реагировать на действия пользователя. Этот модуль выступит в качестве логического процесса, с которым будет взаимодействовать подсистема проведения ДИ. Активных ресурсов, взаимодействующих с ППДИ, может быть несколько, как и логических процессов, используемых при распределенном ИМ. Функции работы самой подсистемы, связанные со временем выполнения операций и событиями, возьмет на себя так называемая управляющая модель (УМ). Работу УМ можно сравнить с управляющей программой в распределенном ИМ, предназначенной для синхронизации логических процессов.
Как основные компоненты моделирования в подсистеме проведения ДИ можно выделить саму подсистему проведения и активные ресурсы, взаимодействие которых с ППДИ будет осуществляться с помощью сообщений. Т.е. вызов активного ресурса будет осуществляться во время выполнения операции, а результатом окончания работы АР будет сообщение подсистеме. Сообщение в рамках ППДИ - это событие, а событие - результат выполнения операции. События в имитационном моделировании - это мгновенное изменение состояния системы.
Предлагается событие сделать видом ресурса, однако события в ППДИ будут двух видов: входной ресурс-событие (РС) и выходной ресурс-событие. Такое разделение необходимо для осуществления управления временем в подсистеме. Входной РС будет знаком для начала выполнения операции, т.е. операция может начать выполняться при наличии входного РС, даже если не наступило время начала операции. Выходной ресурс-событие необходим для перехода к следующей операции. Выходной РС для одной операции является входным РС для другой. Наличие входного или выходного РС для каждой операции задается на этапе проектирования ДИ. Создание выходных РС обеспечивает гарантированный выход из состояния выполнения операции. Также при возникновении активных ресурсов в процессе выполнения операции бизнес-процесса необходимо, чтобы при окончании ЛСА каждого АР происходило формирование события, которое имеет значимость при выполнении операции в основной программе.
События (в нашем случае - операции) должны происходить в хронологическом порядке, т.е. следуя логике и времени. Как было сказано в параграфе 1.2.2, алгоритмы синхронизации модельного времени в распределенном ИМ в нашем случае не подходят, т.к. они учитывают и логику, и время. В СКДИ за логику выполнения отвечает ЛСА, значит, осталось разобраться со временем.
Выполнение операции начинается только тогда, когда есть входной ресурс-событие и текущее время меньше или равно времени наступления выполнения операции. При этом нужно определить, как будет осуществляться продвижение времени при разработке ППДИ. Из рассмотренных в параграфе 1.2.3 алгоритмов продвижения времени продвижение с фиксированным шагом не подойдет, т.к. такое моделирование не будет отражать главного: операция бизнес-процесса должна начать свое выполнение в ППДИ при наступлении времени начала операции, которое у всех операций разное. Моделирование, управляемое часами реального времени, не подойдет, т.к. СКДИ - это студия, содержащая деловые игры, с помощью которых пользователь может получить определенные навыки за короткое моделируемое время.
В таком случае отлично подойдет моделирование с продвижением времени при наступлении события (или на особые моменты времени, или при наличии условий), т.к. в подсистему будут добавлены события, наличие которых позволит перейти к следующей операции. Однако если не было сформировано выходного РС у одной операции, то следующая за ней операция не сможет начаться, т.к. она не будет иметь входного РС.
Физическое время выполнения операций будет задаваться на этапе проектирования ДИ, модельное время выполнения операций будет рассчитываться перед проведением игры, предварительно спросив игрока за какое время он хочет пройти эту игру. Информация о том, какие операции содержат какие входные и выходные ресурсы-события, задается на этапе проектирования деловой игры, как и информация о том, в каких операциях присутствует активный ресурс. Помимо активных ресурсов также на этапе проектирования деловой игры операции присваиваются и другие ресурсы.
Выполнение операции вместе с ее предусловием и постусловием можно представить в виде нескольких шагов:
1. Проверка операции и ресурсов на соответствие.
2. Проверка операции на наличие входного РС.
Выходом из состояния выполнения операции, как было сказано выше, будет точка «Формирование события».
По итогам проецирования элементов распределенного имитационного моделирования на подсистему проведения деловых игр, можно построить следующую таблицу (табл. 1.3):
Таблица 1 .3 . Проецирование распределенного ИМ на ППДИ
Программа синхронизации компонентов моделирования
Взаимодействие программы синхронизации с компонентами моделирования
УП - часть ППДИ. Общение АР с ППДИ с помощью сообщения, ППДИ с АР - программный вызов
Взаимодействие ЛП с коммуникационной системой с помощью интерфейса. Между ЛП - обмен сообщениями
Логическая последовательность объектов
Содержится в коммуникационной подсистеме
Таким образом, определив основные составляющие рассматриваемой подсистемы и обозначив принцип управления временем, следующим шагом необходимо разработать требования к программе, а также новые алгоритмы управления частями ППДИ.
2. Проектирование подсистемы проведения деловых игр с учетом продвижения времени
В данной главе будут представлены требования к программе, определены алгоритмы: алгоритм взаимодействия пользователя с подсистемой проведения ДИ, алгоритм работы самой ППДИ, алгоритм работы модуля «Активный ресурс». Принцип взаимодействия подсистемы проведения ДИ с модулем отражен в диаграмме последовательностей. Разработка таких алгоритмов обусловлена добавлением времени и событий в ППДИ. Также в данной главе описано изменение языка моделей бизне СКДИ.
Основываясь на требованиях, предъявляемых к данному программному продукту в [12, 13] и добавив возможность настройки и моделирования времени, можно разработать следующие функциональные требования к подсистеме проведения ДИ:
1. Пользователь должен иметь возможность задавать модельное время прохождения игры.
2. Управляющая модель выполняет перерасчет физического времени операций на модельное.
3. Автоматная модель выделяет команду из ЛСА.
4. Автоматная модель отправляет команду ОМ.
5. Операционная модель получает команду, выводит на экран все доступные для выполнения очередной операции ресурсы из БД согласно команде.
6. Пользователь должен иметь возможность выбирать ресурсы.
7. ОМ формирует условие, соответствующее действиям пользователя.
8. ОМ проверяет выбранные ресурсы на наличие операции в БД.
9. ОМ отправляет условие управляющей модели.
10. УМ проверяет операции на наличие в БД, на время, на наличие активных ресурсов и ресурсов-событий.
11. УМ формирует выходной ресурс-событие.
13. АМ принимает условие, выполняет поиск ЛСА в БД, выделяет из нее команду.
15. УП проверяет конец времени операции.
16. Пользователь должен иметь возможность получения результата выполнения операции или ошибки после нажатия на кнопку «Выполнить операцию».
17. АМ по условию переходит к п. 3.
2.2 Разработка алгоритма взаимодействия пользователя с ППДИ
Перед тем, как определить функциональные требования, предъявляемые к программе, можно разработать алгоритм взаимодействия игрока с системой с учетом времени:
1. Пользователь задает модельное время прох
Компетентностная деловая игра дипломная работа. Программирование, компьютеры и кибернетика.
Реферат: Тайм-лайн терапия
Хозяйственный Анализ Дипломная Работа
Сочинение Пушкин Лицеист 6 Класс
Курсовая работа по теме Организация производственных процессов на предприятии
Реферат: Охрана окружающей среды 2
Шпаргалка: 4 задачи по основам страхового дела
Дипломная работа по теме Зоотехническая характеристика стада овец сарыаркинской породы и пути ее совершенствования в условиях ПХ 'Руслан' Жамбылского района Алматинской области
Доклад: Курникова Анна Сергеевна
Курсовая Работа На Тему Неотложная Помощь При Гипертензии
Контрольная Работа На Тему Устрій Запорозької Січі
Дипломная Работа На Тему История Возникновения Пластиковых Карт И Перспективы Их Развития
Дипломная работа: Перспективы искусственного разведения щуки в водоемах Амурской области
Темы Диссертации Кандидата Педагогических Наук
Сочинение Совесть Примеры
Реферат: Физико-химические изменения, происходящие при приготовлении блюда Борщ украинский с пампушками
Контрольная работа по теме Структура цены. Акцизы, их сущность и порядок исчисления
Курсовая работа: Изучение приборов и методик определения пиллингуемости текстильных материалов на соответствие ГОСТ 14326-73
Реферат На Тему Герои
Реферат: Обряды и обычаи белорусов
Реферат: Соматическая гимнастика
Специфика каналов распространения рекламы: достоинства и недостатки - Маркетинг, реклама и торговля курсовая работа
Применение методов сетевого планирования при составлении плана закупок материально-технических ресурсов - Менеджмент и трудовые отношения задача
Сделки по торговле объектами интеллектуальной собственности - Государство и право реферат