Full Text

Введение. Образовательные технологии в профессиональной сфере все чаще используют геймификацию обучающих процессов. Под самим термином «геймификация» понимается внедрение игровой механики в неигровые процессы [11]. Внедрение игровой механики подразумевает повышение вовлеченности игрока в процесс обучения путем моделирования условий, с которыми обучаемому придется столкнуться в профессиональной деятельности, с последующей оценкой действий игрока в соответствии с заданным набором компетенций и критериев. Теоретические аспекты и алгоритмы функционирования автоматизированных обучающих систем достаточно глубоко проработаны в работе [4], где подробно рассматриваются различные подходы к проектированию и разработке подобных систем, а также основные принципы взаимодействия обучающегося и системы. На данный момент на рынке деловых игр (ДИ) представлено множество различных программных продуктов [5-10], например, одним из наиболее известных и сложных продуктов является SimulTrain [9]. Однако большинство таких систем фокусируется только на определенной предметной области. В соответствии с принципами геймификации был инициирован проект «Студия компетентностных деловых игр» (далее - СКДИ) [1-3], который позволяет формировать и проверять компетенции, используя деловые игры, построенные на основе реальных бизнес-процессов. Отличительные особенности проекта - это независимость от какой-либо определенной предметной области и возможность использовать в качестве основы любые бизнес-процессы, представленные в той или иной нотации. ДИ определяется, как информационная система, использование которой позволяет выработать у игрока определенного уровня профессиональные компетенции в процессе реализации сценариев, определяемых моделями бизнес-процессов предметной области [1]. Основу СКДИ составляют подсистема проектирования ДИ и подсистема проведения ДИ. Подсистема проектирования должна включать средства для преобразования неформализованного или слабоформализованного описания бизнес-процессов и необходимых для их реализации компетенций к строго формализованным моделям, реализуемым программно-техническим комплексом [2]. Подсистема проведения предназначена для формирования определенного уровня компетенций у игрока на основе выполнения сценария деловой игры и создания деловой обстановки, в которой игрок принимает решения. Для уменьшения уровня сложности подсистемы проведения используется ее декомпозиция на автоматную и операционную модели. Автоматная модель реализует управление, т.е. выполняет алгоритм, заложенный в сценарии деловой игры. Операционная модель выполняет формирование деловой обстановки для игрока на основе команд, поступающих из автоматной модели, и включает в себя модель ресурсов, модель сцены и модель экрана. В настоящей работе осуществляется проектирование интерактивного графического редактора, предназначенного для формирования модели ресурсов и позволяющего связать набор ресурсов с каждой операцией бизнес-процесса. Построение модели процесса «Проектирование деловой игры». Владельцем процесса «Проектирование деловой игры» является проектировщик игры, инициализирующий проектирование новой игры. Основным управляющим документом будет являться инструкция проектировщика, основанная на требованиях к описанию бизнес-процессов в рамках СКДИ, разработанных на предыдущих этапах «Разработка языка для описания реальных бизнес-процессов» и «Разработка языка для описания учебных бизнес-процессов». Игра будет проектироваться с помощью разрабатываемого интерактивного редактора. Разрабатывать игру будет проектировщик. Входным ресурсом для данного процесса является неформальное описание бизнес-процессов предметной области ДИ, например, бизнес-процессов реального предприятия. В качестве выходных ресурсов будут служить следующие: - модели ресурсов, представленные в виде базы данных; - модели экрана; - модели сцены; - логическая схема алгоритма всего бизнес-процесса. Процесс «Проектирование деловой игры» включает в себя следующие операции: - анализ предметной области; - текстовое описание бизнес-процесса; - анализ текстового описания бизнес-процесса; - построение модели реального бизнес-процесса; - построение модели унифицированного учебного бизнес-процесса; - генерация модели унифицированного учебного бизнес-процесса; - заполнение точек принятия решений; - генерация логической схемы алгоритма; - создание моделей ресурсов для каждой операции; - генерация моделей сцены; - генерация моделей экрана; - сохранение моделей в базу данных. При выполнении процесса «Проектирование деловой игры» могут возникать следующие бизнес-события: - преподаватель желает провести деловую игру; - предметная область проанализирована; - бизнес-процесс описан словесно; - бизнес-процесс проанализирован; - модель реального бизнес-процесса построена; - модель унифицированного учебного бизнес-процесса сгенерирована; - точки принятия решений заполнены; - логическая схема алгоритма сгенерирована; - модели ресурсов для каждой операции построены; - модели сцены сгенерированы; - модели экрана сгенерированы; - модели сохранены в базу данных. Модель TO-BE процесса «Проектирование деловой игры» представлена на рис. 1. Преподаватель Преподаватель Проектировщик Редактор Проектировщик Редактор Проектировщик Проектировщик Редактор Проектировщик Проектировщик Проектировщик Проектировщик Редактор Редактор Редактор Редактор Операционная модель Заполнение точек принятия решений Модели сохранены в базу данных Сохранение моделей в базу данных Точки принятия решений заполнены Генерация логической схемы алгоритма Логическая схема алгоритма заполнена Создание модели ресурсов для каждой операции Модели ресурсов сгенерированы Генерация моделей экрана Модели экрана сгенерированы Желание преподавателя провести деловую игру Анализ предметной области Предметная область проанализирована Словесное описание бизнес-процесса Бизнес-процесс описан словесно Бизнес-процесс проанализирован Анализ словесного описания бизнес-процесса Моделирование реального бизнес-процесса Модель реального бизнес-процесса составлена Генерация модели унифицированного учебного бизнес-процесса унифицированного учебного бизнес-процесса сгенерирована Модель Рис. 1. Модель процесса «Проектирование деловой игры» в нотации EPC Исходные данные для операционной модели. Формализация предметной области на этапе проектирования ДИ [3] предполагает преобразование неформализованного или слабоформализованного описания реального бизнес-процесса в унифицированный бизнес-процесс (УБП), который в дальнейшем преобразуется в унифицированный учебный бизнес-процесс (УУБП). УБП может быть достаточно сложным и включать в себя не только последовательные действия, но и различные бизнес-условия, повторяющиеся операции. УУБП кроме операций, содержащихся в УБП, должен содержать операции, реализующие учебную ситуацию в ДИ. Под учебной ситуацией понимается ситуация, в которой игрок принимает решения в процессе выбора ресурсов для выполнения операции БП и/или следующей операции БП и т.д. Для описания УУБП были разработаны взаимосвязанные метамодели с использованием DSM-платформы Metaedit+: Операция, Карта операций и Точка принятия решения [2, 3]. При построении систем автоматизации применяют декомпозицию сложных систем на управляющую (автоматную) и операционную части. Операционная модель (ОМ) выполняет формирование деловой обстановки для игрока на основе команд, поступающих из автоматной модели, и включает в себя модель ресурсов, модель сцены и модель экрана. Рассмотрим процесс автоматизации проектирования ОМ. Исходными данными для ОМ являются метамодели для описания учебных унифицированных бизнес-процессов, а именно «Карта операций», «Операции» и «Точка принятия решений». В них необходимо выделить объекты метамоделей и их атрибуты. Метамодель «Карта операций» включает в себя объекты: · «Начало БП» - для обозначения начала бизнес-процесса; · «Операция» - для представления операции создается объект. Данный объект содержит атрибуты «Название» (типа string), отражает название операции и «Номер» (типа number), отражает идентификационный номер операции; · «Условие» - для представления условия был создан конкретный объект. Данный объект содержит атрибут «Вопрос» (типа text), отражающий условие перехода; · «Завершение БП» - для обозначения завершения бизнес-процесса. Поскольку от объекта «Условие» может быть проведено не более двух связей одновременно к объектам «Завершение БП», «Операция», «Условие», то необходимо было создать абстрактный объект, свойства которого будут наследовать объекты «Завершение БП», «Операция» и «Условие» и который будет контролировать количество выходящих связей. А так как в начале бизнес-процесса может быть либо операция, либо условие, то был создан еще один абстрактный объект, контролирующий, чтобы с объектом «Начало БП» мог быть связан только один из объектов «Операция» или «Условие». Метамодель «Операции» включает следующие объекты: · «Операция» - для представления операции. Данный объект содержит атрибут «Номер» (типа number), отражающий идентификационный номер операции, который служит для связи метамоделей «Операция» и «Карта операций». · «Трудовой ресурс» - для представления трудового ресурса. Данный объект содержит атрибут «Заработная плата» (типа number) - заработная плата трудового ресурса. · «Финансовый ресурс» - для представления финансового ресурса. Данный объект содержит атрибут «Размер» (типа number), который отражает необходимое количество финансовых средств. · «Информационный ресурс» - для представления информационного ресурса. Данный объект содержит атрибут «Дата» (типа string), который отражает дату создания/изменения последней версии документа. · «Товар» - для представления товара. Данный объект содержит атрибуты: - «Количество» (типа number) - количество товара в единицах измерения, указанных ниже; - «Единица измерения» (fixed list) - единица измерения количества товара. · «Услуга» - для представления услуги был создан конкретный объект. Данный объект содержит атрибуты: - «Объем»: (типа number) - затрачиваемое количество рабочих часов на выполнение услуги; - «Направленность» (fixed list) - кому оказывается услуга. Для объектов «Товар» и «Услуга» можно выделить один общий атрибут «Стоимость», поэтому был создан абстрактный объект «Продукт», который отвечает за соответствующую информацию о продукте, а объекты «Товар» и «Услуга» наследуют ее. Данный объект содержит в себе атрибут «Стоимость» (типа number), который отражает стоимость продукта. «Оборудование» - для представления оборудования. Данный объект содержит атрибут «Стоимость эксплуатации» (типа number), который отражает стоимость эксплуатации оборудования. Поскольку ранее описанные объекты «Продукт», «Трудовой ресурс», «Оборудование», «Финансовый ресурс», «Информационный ресурс» являются ресурсами, то было решено создать для них общий абстрактный объект «Абстрактный ресурс», который не содержит атрибутов, но необходим для наглядности логики метамодели. · «Поток» - для представления направления потока ресурсов. · «Контрагент» - для представления контрагента. Так как для ранее описанных объектов «Абстрактный ресурс», «Поток», «Операция», «Контрагент» можно выделить один общий атрибут «Название», необходимо создать абстрактный объект. Объекты «Абстрактный ресурс», «Поток», «Операция», «Контрагент» наследуют информацию абстрактного объекта. Данный объект содержит в себе атрибут «Название» типа string, который отражает название объекта. Метамодель «Точка принятия решений» включает в себя три объекта: · «Вызывающая операция» - содержит в себе название операции, после которой была вызвана точка принятия решения. Соответственно, данный объект включает один атрибут «Название» (типа string). · «Реакция» - представляет собой часть диалога между пользователем и виртуальными оппонентами. Реакция содержит следующие атрибуты: - «Единица диалога» (типа text) - реакция оппонента или одна из возможных реакций игрока; - «Участник диалога» (типа string). Данный атрибут будет содержать в себе роль участника диалога, проявившего реакцию. · «Результирующая операция» отражает название операции, которая должна быть выполнена по завершении диалога (выбор реакции игроком может привести к разным результирующим операциям в рамках одной точки принятия решения). Объекты всех этих метамоделей должны быть включены в модель ресурсов. Выходные данные операционной модели. Модель ресурсов. Ресурс - информационная структура, необходимая для формирования контекста деловой игры и взаимодействия с игроком (документы, рисунки, звуковые файлы, макросы). Модель ресурсов хранится в базе ресурсов и используется для выполнения операции в бизнес-процессе. Модель ресурсов представляется в виде базы данных, которая должна быть нормализована до третьей нормальной формы. «Модель сцены» представляет собой набор ресурсов, из которых пользователь выбирает необходимые для выполнения текущей операции. В зависимости от выбора выполняется оценка действия игрока (штраф). На основе кода сцены и штрафа формируется код состояния игры. Код сцены формируется в сценарии игры и зависит от точки принятия решения [2]. Модель сцены будет представлена как еще один ресурс деловой игры в модели ресурсов. «Модель экрана» управляет выводом ресурсов, используемых в модели сцены, на экран [2]. Существуют три типа моделей экрана: · «Отображение ресурсов». На первой форме модели экрана должны быть отображены все возможные ресурсы для выбранного бизнес-процесса, разбитые по блокам. Выбрав один из ресурсов и щелкнув левой клавишей мыши на ресурс, пользователь запускает открытие второй формы модели экрана. · «Контейнер ресурсов». Вторая форма модели экрана должна отображать все возможные ресурсы для выбранного бизнес-процесса, а также «контейнер», в который пользователь будет добавлять ресурсы для однозначного определения операции. · «Диалог». Диалог должен быть представлен в виде вывода сообщений на экран и нескольких возможных вариантов реакции пользователя. Все последующие автоматические сообщения, помимо первого, зависят от варианта ответа, выбранного пользователем. Проектирование базы данных. Для проектирования схемы базы данных будут использоваться ранее разработанные метамодели «Карта операций», «Операция» и «Точка принятия решений» языка для моделирования учебных бизнес-процессов. Информационные объекты «Модель сцены» и «Модель экрана» не были предусмотрены при разработке метамоделей для описания бизнес-процессов, но они необходимы для формирования интерфейса пользователя, поэтому в рамках подсистемы проектирования должна присутствовать возможность сформировать модель экрана на основе модели сцены, номер которой задается информационной системой. Одна модель сцены может содержать несколько моделей экрана, в которой определено, какие ресурсы и в каком виде будут расположены на экране. Форма модели экрана будет храниться в формате xml. Основные информационные объекты базы данных представлены в табл. 1. Таблица 1 Информационные объекты базы данных Информационный объект Атрибуты Бизнес-процесс Идентификатор, Наименование, Цель Операция Идентификатор, Наименование, Время выполнения, Номер в БП Информационный ресурс Идентификатор, Наименование, Дата создания, Документ, Пиктограмма Финансовый ресурс Идентификатор, Наименование, Количество, Валюта, Пиктограмма Трудовой ресурс Идентификатор, ФИО, Зарплата в час, Должность, Роль в БП, Категория, Пиктограмма Оборудование Идентификатор, Наименование, Стоимость эксплуатации в час, Количество, Пиктограмма Услуга Идентификатор, Наименование, Цена в час, Валюта, Направленность, Время выполнения, Пиктограмма Товар Идентификатор, Наименование, Цена, Валюта, Единица измерения, Количество, Количество на складе, Направленность, Пиктограмма Контрагент Идентификатор, Наименование предприятия, Представитель, Адрес, Телефон, Тип партнерства, Пиктограмма Реакция Идентификатор, Содержание, Оппонент, Родительская реакция, Дочерняя реакция, Вероятность, Идентификатор точки принятия решения Точка принятия решений Идентификатор, Наименование Модель сцены Идентификатор, Наименование, Идентификатор модели экрана, Идентификатор ресурса Модель экрана Идентификатор, Наименование, Форма, Тип Для отображения связей между объектами построим модель предметной области в нотации «Сущность-связь» (рис. 2). Рис. 2. Модель операционной модели в нотации «Сущность-связь» Проектирование интерактивного визуального редактора моделей. Разрабатываемый интерактивный редактор предназначен для построения моделей учебного бизнес-процесса. Модуль редактора для проектирования автоматной модели позволяет смоделировать «Карту операций» и «Точки принятия решений», модуль для проектирования операционной модели отвечает за работу с ресурсами, необходимыми для выполнения каждой операции бизнес-процесса. В рамках данной работы рассматривается возможность построения операционной модели, основанной на метамодели «Операция», реализующей связь между операциями и ресурсами, а также заполнение всех свойств (атрибутов) ресурсов. В соответствии с этим функциональные требования редактора следующие: · При входе в форму заполнения ресурсов должна быть отображена операция, для которой будут заполняться ресурсы, а также реализована область (панель элементов), содержащая элементы для каждого возможного типа ресурсов. · Элемент добавляется в модель при перетаскивании его из панели элементов в область моделирования. · Каждому элементу должен быть присвоен уникальный номер среди элементов, представляющих один и тот же информационный ресурс. · Должна быть реализована возможность удаления элементов модели. · Должна быть реализована проверка на заполнение всех обязательных атрибутов ресурса, а также на соответствие атрибутов синтаксическим правилам языка моделирования. · Должна быть реализована проверка построенной модели на соответствие синтаксическим правилам языка моделирования. · Должна быть реализована возможность сохранения построенной модели. · Редактор должен иметь возможность воспроизвести любую ранее созданную и сохраненную модель, хранимую в базе данных. В табл. 2 приведено соответствие прецедентов функциональным требованиям, описанным ранее. Таблица 2 Соответствие прецедентов функциональным требованиям Требование Субъект Прецедент При входе в форму заполнения ресурсов должна быть отображена операция, для которой будут заполняться ресурсы, а также реализована область (панель элементов), содержащая элементы для каждого возможного типа ресурсов Проектировщик Вывести форму графического редактора для создания модели ресурсов операции Элемент добавляется в модель при перетаскивании его из панели элементов в область моделирования Проектировщик Добавить элемент в модель (при перетаскивании пользователем его из панели элементов в область модели) Каждому элементу должен быть присвоен уникальный номер среди элементов, представляющих один и тот же информационный ресурс Проектировщик Отобразить атрибуты элемента (при двойном щелчке по элементу) Должна быть реализована проверка на заполнение всех обязательных атрибутов ресурса, а также на соответствие атрибутов синтаксическим правилам языка моделирования Проектировщик Проверить заполнение всех обязательных атрибутов Должна быть реализована проверка на заполнение всех обязательных атрибутов ресурса, а также на соответствие атрибутов синтаксическим правилам языка моделирования Проектировщик Проверить атрибуты на соответствие синтаксическим правилам Должна быть реализована проверка построенной модели на соответствие синтаксическим правилам языка моделирования Проектировщик Проверить модель на соответствие синтаксическим правилам Окончание табл. 2 Требование Субъект Прецедент Должна быть реализована возможность сохранения модели и выгрузки в файл Проектировщик Сохранить модель Необходима возможность заполнения соответствующих информационных объектов в базе данных при сохранении модели Проектировщик Заполнить информационные объекты в базе данных Редактор должен иметь возможность воспроизвести любую ранее созданную и сохраненную модель, хранимую в базе данных Проектировщик Загрузить ранее сохраненную модель Должна быть реализована возможность удаления элементов модели Проектировщик Удалить элемент Диаграмма прецедентов представлена на рис. 3. Рис. 3. Диаграмма прецедентов Описание прецедентов приведено ниже. Описание прецедентов Прецедент Вывести форму графического редактора для создания модели ресурсов операции Краткое описание Прецедент отвечает за графический интерфейс, представленный пользователю в качестве графического редактора Актер Проектировщик Предусловия Пользователь нажал «Перейти к заполнению ресурсов» в форме для формирования карты операций Основной поток Форма отображает 5 областей: 1. Область панели элементов. 2. Область моделирования. 3. Область атрибутов (свойств). 4. Область панели инструментов. 5. Область инициализации. Альтернативный поток Нет Постусловия Если прецедент был успешным, то пользователь может приступить к созданию модели Прецедент Добавить элемент в модель (при перетаскивании пользователем его из панели элементов в область модели) Краткое описание Прецедент дает возможность составить модель ресурсов для каждой операции с помощью выбора различных элементов Актер Проектировщик Предусловия Запущена форма графического редактора для создания модели ресурсов операции Основной поток Проектировщик выбирает операцию бизнес-процесса, для которого создается модель. Проектировщик перетаскивает элемент в область модели, удерживая левую клавишу мыши. Элемент отображается в области модели. Проектировщик может редактировать размеры элемента Альтернативный поток Если не выбрана операция, то область панели элементов пуста, соответственно, проектировщик не может выбрать элемент Постусловия Проектировщик может перейти к заполнению атрибутов (свойств) элемента Прецедент Отобразить атрибуты элемента (при выделении элемента левой клавишей мыши) Краткое описание Прецедент позволяет заполнить свойства элемента (ресурса) Актер Проектировщик Предусловия Элемент перенесен в область модели Основной поток Проектировщик выделяет элемент. В области атрибутов (свойств) отображаются атрибуты выбранного типа ресурса. Проектировщик заполняет все или часть атрибутов Альтернативный поток Нет Постусловия Запускается проверка правильности заполнения обязательных атрибутов Прецедент Проверить заполнение всех обязательных атрибутов Краткое описание Прецедент позволяет обнаружить незаполненные обязательные атрибуты Актер Проектировщик Предусловия Проектировщик нажал на кнопку «Сохранить» Основной поток Выполняется перебор обязательных атрибутов элемента модели. Если атрибут отмечен как обязательный, то он должен быть заполнен Альтернативный поток Если заполнены не все обязательные поля, то выдается сообщение об ошибке и модель не сохраняется Постусловия Запускается проверка правильности атрибутов синтаксическим правилам языка моделирования Прецедент Проверить атрибуты на соответствие синтаксическим правилам Краткое описание Прецедент позволяет обнаружить синтаксические ошибки при заполнении атрибутов Актер Проектировщик Предусловия Проектировщик нажал на кнопку «Сохранить», и все обязательные атрибуты заполнены. Основной поток Выполняется перебор атрибутов элемента. Для каждого атрибута выполняется проверка на соответствие заданному типу данных и заданному для атрибута диапазону Альтернативный поток При неправильном заполнении атрибута на экране появляется сообщение об ошибке Постусловия Если прецедент завершился успешно, то модель сохраняется в базу данных Прецедент Проверить модель на соответствие синтаксическим правилам Краткое описание Прецедент позволяет проверить всю модель на соответствие синтаксическим правилам метамодели. Актер Проектировщик Предусловия Построена вся модель или ее часть Основной поток Пользователь нажимает на кнопку «Сохранить». Построенная модель проверяется системой на соответствие синтаксическим правилам метамодели Альтернативный поток Если модель содержит синтаксические ошибки, то на экран выводятся сообщение об ошибке и ее краткое описание Постусловия Если прецедент был успешным, то запускается проверка на соответствие атрибутов синтаксическим правилам Прецедент Сохранить модель Краткое описание Прецедент позволяет сохранить модель как информационные объекты в базе данных, а также ее графическое представление Актер Проектировщик Предусловия В области моделирования отображена модель Основной поток Проектировщик нажимает на кнопку «Сохранить». Выполняется проверка модели на соответствие синтаксическим правилам языка моделирования Выполняется проверка заполнения всех обязательных атрибутов модели. Выполняется проверка правильности заполнения атрибутов в соответствии с синтаксическими правилами. Все элементы модели сохраняются Альтернативный поток Если модель или атрибуты элементов содержат ошибки, то выводится сообщение об ошибке и модель не сохраняется Постусловия Модель сохранена в базу данных Прецедент Загрузить ранее сохраненную модель Краткое описание Прецедент позволяет загрузить ранее сформированную и сохраненную в базе данных модель Актер Проектировщик Предусловия Модель ранее была сохранена в базе данных, и графический редактор запущен Основной поток Проектировщик выбирает бизнес-процесс, для которого необходимо загрузить модель. Проектировщик выбирает операцию, для которой необходимо загрузить модель. Проектировщик нажимает на кнопку «Загрузить». Модель выводится на экран Альтернативный поток Если проектировщик не выбрал бизнес-процесс, то список операций для загрузки будет пуст. Если проектировщик не выбрал бизнес-процесс или операцию для загрузки, то при нажатии на кнопку «Загрузить» не произойдет ни одного события Постусловия Модель выведена на экран и может быть отредактирована Прецедент Удалить элемент Краткое описание Прецедент позволяет удалять элементы из модели Актер Проектировщик Предусловия Отображена форма графического редактора Основной поток Проектировщик выделяет элемент посредством левой клавиши мыши. Проектировщик нажимает на кнопку «Удалить». Элемент удаляется из модели Альтернативный поток Если не выделен ни один элемент, то кнопка «Удалить» не будет доступна Постусловия Модель выведена на экран и может быть отредактирована На этапе проектирования редактора была построена диаграмма классов с учетом разделения на классы представления, управления и сущностей, представленная на рис. 4. Рис. 4. Диаграмма классов графического редактора на этапе проектирования Диаграмма классов разбивается на 3 части в соответствии с паттерном MVC: - классы сущностей (model), отражают бизнес-логику приложения; - классы представления (view), отвечают за визуализацию модели данных; - классы управления (control), обеспечивают взаимодействие пользователя с моделью данных. Заключение. В настоящей работе осуществляется проектирование интерактивного графического редактора, предназначенного для формирования модели ресурсов и позволяющего связать набор ресурсов с каждой операцией бизнес-процесса. В качестве дальнейших действий необходимо разработать алгоритм формирования моделей сцены и моделей экрана, которые должны быть сгенерированы автоматически на основе трех видов моделей бизнес-процесса.

About the authors

O. L Vikentyeva

National Research University «Higher School of Economics»

A. I Deriabin

National Research University «Higher School of Economics»

N. V Krasilich

National Research University «Higher School of Economics»

L. V Shestakova

National Research University «Higher School of Economics»

References

Statistics

Views

Abstract - 16

PDF (Russian) - 8

Refbacks

• There are currently no refbacks.