Платформа Flexberry будет использована для создания «скелета» веб-приложения, на основании которого будет производиться разработка имитационной системы. Flexberry Platform позволяет создавать приложения с использованием следующих технологий:
1) Ember.JS / ASP.NET Web Api в качестве клиентского фреймворка.
2) PHP / Java / ASP.NET Web Api в качестве серверного фреймворка.
3) Microsoft SQL Server / Postgres SQL / Oracle в качестве СУБД.
Ember.JS был выбран в качестве клиентского фреймворка, так как он является фреймворком одностраничных приложений (SPA - single page application), позволяет гибко настроить пользовательский интерфейс и обеспечивает удобство в работе с объектами.
В качестве программных продуктов, работающих на стороне сервера, был выбраны ASP.Net Web Api и Microsoft SQL Server, так как разработчик приложения имеет опыт работы с языком программирования C# и СУБД MS SQL Server.
Таким образом, в приложении будут использоваться следующие средства:
1. Ember.JS - «front-end» фреймворк.
2. Сервер ASP.NET - «back-end» фреймворк.
3. Flexberry ORM.
4. Microsoft SQL Database - СУБД.
5. Azure Microsoft SQL Database Server - удалённый сервер баз данных.
База данных приложения будет расположена на удалённом сервере Microsoft Azure. Это позволит обращаться к БД через сеть интернет и позволит взаимодействовать с ней другим разработчикам проекта «СКДИ». Это также позволит иметь возможность загрузить клиентское приложение на удалённый сервер, полностью освободившись от необходимости запускать подсистему в локальной сети.
В результате, схема взаимодействия компонентов приложения будет иметь вид, указанный на рис. 2.15. Игрок взаимодействует с клиентским приложением Ember.JS, участвуя в игровом процессе. Клиентское приложение получает команды пользователя и в случае необходимости получает данные от сервера ASP.Net с помощью веб-запросов.
Рисунок 2.15. Схема взаимодействия компонентов приложения
Сервер ASP.Net использует REST API, ранее сгенерированный платформой Flexberry, чтобы интерпретировать запросы клиентского приложения. В ответ на запрос от приложения Ember.JS, сервер ASP.Net получает информацию об игровых ресурсах с помощью Flexberry ORM, и возвращает результат веб-запроса обратно клиенту. Пример запроса на загрузку и запуск бизнес-процесса указан на рис. 2.16.
Рисунок 2.16. Обработка команды пользователя «Запуск бизнес-процесса»
2.4.3 Обеспечение синхронной загрузки данных
Flexberry ORM использует асинхронные запросы к серверу для получения объектов из базы данных. Это означает, что при проектировании алгоритмов интерпретатора строки ЛСА, необходимо обрабатывать асинхронные запросы Flexberry ORM и выполнять действия синхронно, то есть только после завершения загрузки объекта из базы данных.
На рисунке 2.17 приведён пример необработанной асинхронной загрузки объекта. В момент, когда команда ЛСА на загрузку БП была обработана (операция 1.1 на рис. 2.17), интерпретатор использует асинхронную функцию Flexberry ORM для загрузки объекта. В случае если асинхронный запрос не будет обработан, интерпретатор продолжит выполнение функции, не дожидаясь окончания загрузки.
Рисунок 2.17. Пример необработанной асинхронной загрузки объекта
Следовательно, необходимо обрабатывать асинхронные запросы на загрузку объектов во избежание ошибок. Существует два способа обработки асинхронных запросов в JavaScript:
1) вспомогательный класс «Promise»,
2) конструкция async/await.
Так как Ember.JS не поддерживает использование конструкций async/await, в проектируемом приложении необходимо использовать библиотеку RSVP.Promise для обработки асинхронных запросов. В таком случае в приложении не будет возникать ошибок, связанных с незагруженными объектами (см. рис. 2.18). На представленном рисунке показан пример обработанного асинхронного запроса.
Рисунок 2.18. Пример обработанной асинхронной загрузки объекта
2.5 Вывод
В итоге, был использован метод агентного моделирования при проектировании архитектуры подсистемы проведения. Алгоритм продвижения времени системы был описан с учётом выбранного метода моделирования.
Для активных ресурсов был спроектирован алгоритм продвижения времени, учитывающий действия, выполняемые активными ресурсами. Алгоритм был спроектирован с учётом принципов СКДИ, в частности с использованием интерпретатора логической схемы алгоритма. Спроектированные алгоритмы позволят создать деловую игру по рассматриваемому сценарию.
Архитектура приложения была спроектирована с учётом необходимости использования реляционной базы данных. Загрузка игрового сценария из реляционной БД позволит осуществить интеграцию с подсистемой проектирования.
Глава 3. Реализация подсистемы проведения
Этап реализации включает в себя генерацию веб-приложения, программирование алгоритмов загрузки и интерпретации игрового сценария, настройку пользовательского интерфейса и публикацию веб-приложения в интернет.
3.1 Генерация веб-приложения с помощью Flexberry Platform
Первый этап в разработке подсистемы проведения - это генерация приложения с помощью CASE-инструментария Flexberry. Генерация приложения с помощью Flexberry позволяет создать «каркас» будущей подсистемы, содержащий необходимые инструменты для загрузки игрового сценария.
Перед генерацией приложения необходимо создать диаграмму классов UML. Во Flexberry была построена диаграмма классов, аналогичная той, что была построена на этапе проектирования игрового сценария (см. рис 2.6, рис 3.1).
Рисунок 3.1. Диаграмма классов подсистемы проведения
Для каждого класса были заданы его представления (см. рис 3.2). Представление представляет собой описание атрибутов класса или связанных с ним классов, с целью сохранения необходимых данных в одном объекте. Представления используются для генерации форм редактирования и просмотра, а также для генерации классов объектно-реляционного преставления (ORM), с помощью которых будет загружаться игровой сценарий.
Рисунок 3.2. Настройка представления класса «Ресурс»
Формы редактирования и просмотра списка объектов были автоматически сгенерированы для каждого класса на основании заданных представлений. Например, на рис. 3.3 показана форма редактирования игровых ресурсов.
Рисунок 3.3. Редактирование ресурса «Бюджет проекта»
При генерации приложения было создано 15 моделей объектно-реляционного представления (ORM), которые могут быть использованы для загрузки данных из БД (см. рис 3.4). Каждая модель представлена в виде объекта Ember.Object, хранящего информацию о:
1) представлениях модели, заданных с помощью Flexberry Designer,
2) загружаемых вместе с представлением атрибутах,
3) правилах валидации модели, несоблюдение которых не позволит сохранить модель.
Рисунок 3.4. Структура папок приложения Ember.JS. Папка с моделями объектно-реляционного представления (ORM).
В результате генерации приложения, было получено следующее:
1) клиентское приложение Ember.JS,
2) серверное приложение ASP.NET Web API,
3) база данных Microsoft SQL Server.
Клиентское и серверное приложения были запущены и настроены для работы в локальной сети. Архитектура сгенерированного веб-приложения соответствует рис. 2.15. Серверное приложение успешно принимает веб-запросы от клиента.
Таким образом, процесс генерации позволил создать приложение, позволяющее работать с базой данных игрового сценария через веб-приложение. Кроме того, для каждого объекта базы данных была сгенерирована модель, с помощью которой можно загрузить игровой сценарий.
3.2 Реализация страницы игры
Внешний вид страницы был создан с помощью шаблонизатора Handlebars, который является частью фреймворка Ember.JS. Использование шаблонизатора позволило динамически загружать и отображать игровые ресурсы. Для каждого из ресурсов был создан свой «компонент». Компоненты используются для настройки внешнего вида отдельных элементов модели.
Всего в приложении было создано 4 компоненты:
1) Arinstance-info - отображает активных игровых агентов.
2) Resource-choice - отображает игровой ресурс, который пользователь может выбрать.
3) Resource-info - отображает игровой ресурс, который не может быть выбран пользователем.
4) Process-info - информация об активном процессе (для страницы отладки).
Ember.JS использует концепцию DDAU - «данные вниз - действия вверх». Это означает, что каждый компонент должен получать данные от своего родителя. Например, в шаблоне «arinstance-info» это реализовано следующим образом. Внутрь компоненты поступает модель: экземпляр активного ресурса разработчик «Мария» (в табл. 3.1 - это «arimodel»). Компонент, получив данные, отображает их в соответствии со своим шаблоном (табл 3.1).
Описание компоненты «Экземпляр АР»
|
Код вызова компоненты |
Код компоненты |
Результат работы |
|
|
{{arinstance-info arinstance=arimodel showAmount=true}} |
<div class="header"> {{arinstanceType.name}} {{arinstance.name}} </div> <div class="description"> {{#each attributes as |attribute|}} <p>{{attribute.name}}: {{attribute.amount}}</p> {{/each}} </div> |
Аналогичным образом происходит отображение остальных видимых моделей на сцене. Код остальных компонент и их шаблонов можно посмотреть в приложении C. Таким образом, компоненты позволяют отображать ресурсы на сцене.
Загрузка игровых ресурсов на сцену производится с помощью инструмента Flexberry Query, который позволяет обращаться к серверу ASP.NET с установленным пакетом Flexberry ORM. Запрос строится с помощью специального языка запросов. Рассмотрим функцию загрузки ресурса на сцену (см. рис. 3.5).
Перед началом загрузки ресурса, создаётся условие SimplePredicate, в котором указывается, что необходимо получать только те ресурсы, которые имеют указанный код. Затем строится запрос на получение ресурса из БД с помощью функции Query.Builder. Query.Builder содержит информацию о представлении, по которому необходимо совершить загрузку ресурса (ResourceE), о типе загружаемой модели (n-i-b-g-resource) и о наборе ограничений (byCode).
|
loadResource(code) { var self = this; //Сохраняем контекст //Строим запрос: var byCode = new SimplePredicate('code', Query.FilterOperator.Eq, code); let builder = new Query.Builder(this.get('store')) .from('n-i-b-g-resource') .selectByProjection('ResourceE') .where(byCode); //Вызываем запрос (асинхронный метод): return self.get('store').query('n-i-b-g-resource', builder.build()) .then((result) => { let resource = result.get('firstObject'); console.log('Загружен ресурс: ' + code); return resource; }); }, |
Рисунок 3.5. Метод загрузки ресурса из БД
После этого сформированный запрос на получение ресурса вызывается асинхронно. Согласно требованиям, асинхронный запрос должен быть обработан с помощью класса Promise. Это выполняется с использованием «callback-метода» .then(), который вызывается после завершения выполнения асинхронного запроса. Результат выполнения функции - это класс Promise, возвращающий загруженный ресурс. Загрузка всех остальных объектов выполняется аналогично.
Таким образом, была реализована главная страница игры (рис 3.6). На экране отображается игровое время, бюджет и список активных игровых агентов (активных ресурсов в состоянии «занят»). Игра начинается по кнопке «запустить процесс».
Страница игры
После успешной загрузки бизнес-процесса, подсистема проведения запускает процесс разбора строки ЛСА. Интерпретация ЛСА реализуется с использованием рекурсивной функции разбора строки. Интерпретация строки ЛСА происходит в три этапа: извлечение команды, логирование и выполнение команды.
В процессе игры, участнику может быть предложено выбрать игровой ресурс. В реализуемом сценарии - это выбор плана проекта, по которому будет происходить симуляция бизнес-процесса (рис. 3.7). После того, как игрок выберет игровой ресурс, активные ресурсы (сотрудники) выполнят свои операции согласно своим бизнес-процессам.
Модальное окно выбора ресурса
Продвижение игрового времени происходит во время разбора строки ЛСА. В случае, если существует хотя бы один активный игровой агент, метод продвижения времени выполнится у всех игровых агентов (рис. 3.8). Алгоритм продвижения времени игровых агентов указан в приложении D.
|
tick() { var acitveAgents = this.get('agents.active'); if (acitveAgents.length > 0) { //Получить список всех агентов: var agents = this.get('agents'); //Вызвать метод продвижения времени: agents.forEach(function (ag) { ag.tick() }); //Увеличить игровое время на 1 ед: var time = this.get('time'); self.set('time', time + 1); } else { this.nextLSACommand(); } }, |
Рисунок 3.6. Метод продвижения времени контроллера
Для подсистемы проведения была реализована страница отладки (рис. 3.9), в которой записывается последовательность разобранных команд строки ЛСА. На этой странице также отображаются обработанные ошибки и список активных (исполняющихся) на данный момент процессов.