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

Разработка прототипа редактора для информационной системы проектирования и проведения деловых игр

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

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

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

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

Страница:

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

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

«Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

Разработка прототипа редактора для информационной системы проектирования и проведения деловых игр

Бартош Валерия Александровна

Пермь, 2019 год

Аннотация

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

Оглавление

Введение

1. Анализ предметной области

1.1 Концепция СКДИ

1.2 Анализ процесса проектирования деловых игр

1.3 Анализ работы подсистемы проектирования

1.4 Усовершенствование моделей

1.5 Разработка метамоделей

1.6 Определение требований к редактору

1.7 Выбор инструментов для разработки

2. Проектирование редактора

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

2.2 Проектирование интерфейса

2.3 Проектирование алгоритма преобразования УБП в УУБП

2.4 Проектирование алгоритма преобразования УУБП в ЛСА

3. Разработка прототипа редактора

3.1 Создание БД

3.2 Разработка интерфейса

3.3 Разработка серверной части

Заключение

Библиографический список

Приложение

Введение

За последние два десятилетия появилось множество различных методов обучения как студентов, так и работников профессиональных сфер деятельности. Одним из таких методов является деловая игра, применяемая в организациях. Данный метод применяется для развития индивидуальных способностей и компетенций, поскольку является эффективным с точки зрения подготовки как студентов к рабочей атмосфере, так и для обучения работников новым навыкам [1, 2].

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

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

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

Объектом исследования является процесс проектирования деловой игры с помощью СКДИ.

Предметом исследования являются автоматизированные средства для проектирования деловой игры.

Целью данной работы является создание прототипа редактора для проектирования деловой игры в СКДИ.

Для того чтобы достигнуть цели необходимо выполнить следующие задачи:

1. Проанализировать процесса проектирования и проведения деловых игр.

2. Проанализировать действующие решения для разработки редактора.

3. Разработать требования к редактору.

4. Внести изменения в предметно-ориентированный язык для учета времени БП и их синхронизации во времени.

5. Разработать сценарий и алгоритмы работы редактора.

6. Спроектировать интерфейс и базу данных.

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

8. Разработать и протестировать программный продукт.

Результатом выполненной работы будет являться прототип web-редактора, который в дальнейшем будет взят за основу для разработки полноценного редактора для информационной системы проектирования и проведения деловой игры СКДИ.

1. Анализ предметной области

1.1 Концепция СКДИ

Проект СКДИ разрабатывается сотрудниками кафедры информационных технологий в бизнесе НИУ ВШЭ Пермь. Реализация проекта происходит с помощью сил как преподавателей, так и студентов. В основу СКДИ легла необходимость в создании деловой игры, предназначенной для развития профессиональных компетенций, где пользователями могут выступать как студенты, так и работники профессиональной сферы. При этом деловая игра не должна основываться на одной предметной области, а должна давать возможность разрабатывать деловые игры в разных профессиональных областях. В рамках СКДИ была разработана собственная архитектура системы, изображенная на рисунке 1.1 [2].

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

Каждая подсистема исполняет свою роль, которая приведена в таблице 1.1.

Таблица 1.1. Роли подсистем СКДИ

Название подсистемы

Роль подсистемы

Проектирования

Описание БП, на основе которого проектируется/создается сценарий, по которому проводится игра.

Проведения

Проведение деловой игры в соответствии с созданным сценарием.

Мониторинга

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

Анализа

Анализ итогов и результатов проведения ДИ.

Измерения

Оценки количества и/или уровня выработанных в ходе проведения ДИ компетенций и навыков (субъект - игрок).

Корректировки

Создание и применение корректировок сценария ДИ на основе результатов, полученных из подсистемы анализа.

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

1.2 Анализ процесса проектирования деловых игр

Подсистема проектирования предназначена для преобразования описанного бизнес-процесса в сценарий деловой игры. Данная подсистема имеет сложную многокомпонентную архитектуру, которая представлена на рисунке 1.2 [2].

Рисунок 1.2. Проектирование деловой игры

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

Рисунок 1.3. Схема работы подсистемы проектирования и проведения ДИ

Для того чтобы обеспечить работоспособность подсистемы проведения деловой игры, необходимо реализовать два вида моделей: первая из которых - автоматная модель (ЛСА, сгенерированная в процессе проектирования), функционально ответственная за грамотное соблюдение алгоритма, являющегося программными базисом сценария; вторая - операционная модель, которая позволяет произвести развёртывание деловой обстановки, принимая за основу сведения, получаемые из автоматной модели [4, 9, 10, 12]. Операционная модель агрегирует в себе ряд моделей, которые являются неотъемлемыми компонентами обстановки: модель сцены, ресурсов, экрана.

1.3 Анализ работы подсистемы проектирования

Преобразование РБП в УБП

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

УБП представляет собой упрощенную версию РБП, где упрощенность заключается в отсечении лишней информации, не влияющей на основное содержание БП. УБП представляет собой описание БП, состоящее из операций, которые могут как выполняться последовательно, так и иметь условные ответвления. В качестве описания РБП принято использовать модель БП в нотации IDEF0 [8]. Основными преимуществами этой нотации является:

· Полнота описания БП (вход, выход, управление, механизмы);

· Возможность декомпозиции операции для подробного описания;

· Агрегация и детализация потоков данных.

Рассмотрим упрощенный вариант рабочего БП «Подготовка тем курсовых работ для приказа», изображенный на рисунке 1.4.

Рисунок 1.4. «Подготовка тем КР для приказа» в нотации IDEF0

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

Результат представлен в таблице 1.2.

Таблица 1.2. Информация об операциях в БП «Подготовка тем КР для приказа»

Номер операции

Название операции

Входящие ресурсы

Выходящие ресурсы

Ресурсы управления

Механизмы

А1

Сформировать список тем

Список тем от научных руководителей

Список тем для студентов

Положение о КР/ВКР

Академический руководитель, Текстовый редактор

А2

Отправить темы студентам

Список тем для студентов

Список тем от студентов

Положение о КР/ВКР

Студент, Электронная почта

А3

Сформировать список тем для приказа

Список тем от студентов

Список тем для приказа

Положение о КР/ВКР

Академический руководитель, Текстовый редактор

БП могут быть сложными и простыми, под сложностью БП понимается присутствие в операции вложенных БП. На примере выбранного БП «Подготовка тем КР для приказа», операция «Отправить темы студентам» имеет вложенный БП, который выполняется каждым агентом активного ресурса. Данная операция подразумевает, что после отправки тем академическим руководителем, студенты должен выбрать тему из предложенных или же предложить свою тему и проинформироваться академического руководителя. Соответственно студент будет выступать как активный ресурс (АР), причем под студентом подразумевается каждый студент группы, которой нужно выбрать тему для курсовой работы (КР) [7]. В связи с этим возникает вложенный БП «Выбор тем студентом» представленная на рисунке 1.5.

Рисунок 1.5. «Выбор тем студентом» в нотации IDEF0

Описание операций и ресурсов, входящих в работы «активного ресурса», представлены в таблице 1.3.

Таблица 1.3. Информация об операциях в БП «Выбор тем студентом»

Номер операции

Название операции

Входящие ресурсы

Выходящие ресурсы

Ресурсы управления

Механизмы

А21

Выбрать тему из списка

Список тем для студентов

Выбранная тема

Предпочтения

Студент

А22

Предложить свою тему

Список тем для студентов

Предложенная тема

Идеи

Студент

А23

Отправить тему академическому руководителю

Выбранная/ предложенная тема

Тема

-

Студент

После того, как выделены ресурсы, используемыми операциями, и роли, задействованные в них, необходимо построить упрощенный рабочий БП «Подготовка тем КР для приказа» в нотации УБП. В нотации УБП используются элементы, представленные в таблице 1.4.

Таблица 1.4. Описание элементов нотации УБП

Название элемента

Элемент в нотации УБП

Для последовательности операций

Начало БП

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

Конец БП

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

Операция

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

Условие

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

Для описания ресурсов

Ресурс

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

Направление стрелок направлены от блока «Начало БП» к блоку «Конец БП». В случае, если БП состоит из операций, которые выполняются друг за другом, то из блока условия не используется и из каждого созданного блока «Операция» входит и выходит по одной стрелки, которая обозначает переход к следующему блоку. Если же БП имеет Условие, которое определяет переход на ту или иную операцию, то из блока «Условие» должно быть две исходящие стрелки, которое направлены в две разные операции.

Как было определено ранее, БП имеет 3 последовательные операции без условных ответвлений, что и представлено на рисунке 1.6.

Рисунок 1.6. «Подготовка тем КР для приказа» в нотации УБП

После того, как создан общий алгоритм выполнения БП, для каждой операции строится схема, описывающая ресурсы для каждой операции отдельно. Группы ресурсов, относящихся к одной операции, также делятся на входящие и выходящие ресурсы, ресурсы управления и механизмы [11]. Ресурсы, описывающие операции, могут повторяться, так как ресурс, выходящий из предыдущей операции, может использоваться в последующих операциях как один раз, так и несколько.

Пример описания операций, входящих в БП, представлен на рисунках 1.7.

Рисунок 1.7. Ресурсы операции «Сформировать список тем»

С описанием остальных операций можно ознакомиться в приложении А.

Было определено, что операция «Отправить темы студентам» имеет вложенный БП «Выбрать тему КР», выполняемый активным ресурсом. Каждая операция вложенного БП совершается множеством студентов, которым необходимо отправить выбранную тему академическому руководителю. Для активного ресурса тоже создается описание, которое представлено на рисунке 1.8. и в приложении А.

Рисунок 1.8. Вложенный БП «Выбрать тему КР» в нотации УБП

В процессе описания ресурсов необходимо задать ключевые ресурсы. Ключевой ресурс - ресурс, без которого операция не может быть выполнена, поэтому его указание является первоочередной задачей. Если ключевой ресурс не был выбран игроком в процессе выбора ресурсов для перехода на соответствующую операцию, проведение игры будет невозможно, поскольку ни одна операций не будет выполнена. В таком случае игра закончится ошибкой. Отметим все ключевые и не ключевые ресурсы и присвоим им идентификационные номера внутри БП в таблице 1.5., приняв обозначение «*» за ключевой ресурс.

Таблица 1.5. Ресурсы БП «Подготовка тем КР для приказа»

Код операции

Название операции

Код ресурса

Название ресурса

Примечание

А1

Сформировать список тем

R1*

Список тем от научных руководителей

А1

Сформировать список тем

R2

Список тем для студентов

А1

Сформировать список тем

R3

Положение о КР/ВКР

А1

Сформировать список тем

R4

Академический руководитель

Исполнитель

A1

Сформировать список тем

R5

Текстовый редактор

A2

Отправить темы студентам

R2*

Список тем для студентов

A2

Отправить темы студентам

R6

Список тем от студентов

A2

Отправить темы студентам

R3

Положение о КР/ВКР

A2

Отправить темы студентам

R7

Студент

Активный ресурс

A2

Отправить темы студентам

R4

Академический руководитель

Исполнитель

A2

Отправить темы студентам

R8

Электронная почта

A3

Сформировать список тем для приказа

R6*

Список тем от студентов

A3

Сформировать список тем для приказа

R9

Список тем для приказа

A3

Сформировать список тем для приказа

R3

Положение о КР/ВКР

A3

Сформировать список тем для приказа

R4

Академический руководитель

Исполнитель

A3

Сформировать список тем для приказа

R5

Текстовый редактор

A21

Выбрать тему из списка

R2*

Список тем для студентов

A21

Выбрать тему из списка

R21

Выбранная тема

A21

Выбрать тему из списка

R22

Предпочтения

A21

Выбрать тему из списка

R25

Студент

Активный ресурс

A22

Предложить свою тему

R2*

Список тем для студентов

A22

Предложить свою тему

R23

Предложенная тема

A22

Предложить свою тему

R24

Идеи

A22

Предложить свою тему

R25

Студент

Активный ресурс

A23

Отправить тему академическому руководителю

R21* / R23*

Выбранная/предложенная тема

A23

Отправить тему академическому руководителю

R26

Тема

A23

Отправить тему академическому руководителю

R27

Студент

Активный ресурс

Согласно логике работы подсистемы проектирования после того, как сформировано описание БП, дальнейшим шагом является построение унифицированного учебного БП (УУБП).

Преобразование УБП в УУБП

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

Таблица 1.6. Описание элементов нотации УУБП

Название элемента

Элемент в нотации УБП

Начало БП

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

Конец БП

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

Операция

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

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

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

Ошибка

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

При построении схемы УУБП нужно учесть, что игрок начинает свою игру с точки принятия решения, где может определяться, будет ли успешен переход на ту или иную операцию, а также будет ли игра продолжиться или же будет закончена с ошибкой. Элементы для описания УУБП представлены в таблице 1.6.

В соответствии с элементами, которые используются в построении модели УУБП была построена схема УУБП для БП, состоящего из трех последовательных операций для БП «Подготовка тем КР для приказа». Построенная схема представлена на рисунке 1.9.

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

Рисунок 1.9. Схема УУБП «Подготовка тем КР для приказа»

Точка принятия решения этапа - это момент в игре, в котором, происходит выбор ресурсов, а затем проверка условий для перехода на следующую операцию. Условия проверки достаточно просты: главной задачей игрока является выбор ключевого ресурса для операции. Если ресурс определён верно, игра продолжается и происходит переход к следующей операции. Если же игрок выбирает ошибочный ресурс или же определяет ключевым ресурсом не ключевой, возникает ошибка хода игры.

Вложенный БП активного ресурса имеет аналогичную логику действий. В выбранном нами БП прежде всего необходимо перейти к операции «А2» основного БП, после чего у игрока появится возможность перейти к операции вложенного БП и выполнять операции активного ресурса. После выполнения всех операций вложенного БП активного ресурса будет совершено переход на операцию «А3», и игра будет успешно завершена. Построение УУБП вложенного БП активного ресурса имеет логику, аналогичную построению УУБП основного БП. Построенная схема представлена на рисунке 1.10.

Рисунок 1.10. Вложенный БП операции

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

Преобразование УУБП в ЛСА

Модель УУБП служит основой для формирования логической схемы алгоритма (ЛСА). Данная схема представляет собой конечный автомат, описывающий последовательность сцен, переходов и вызовов ресурсов деловой игры. ЛСА лежит в основе автоматной модели, которая реализует механизм управления ходом деловой игры. Выражение на языке ЛСА можно представить следующим образом: L= {Н, А, Р, щ, ^, v, К} обозначения множества языка ЛСА указаны в таблице 1.7.

Таблица 1.7. Обозначения множества языка ЛСА

Обозначение

Значение

Н

оператор начала алгоритма

К

оператор конца алгоритма

Р

условный переход

А

управляющее воздействие

щ

безусловный переход

^

начало перехода

v

окончание перехода

Для БП «Подготовка тем КР для приказа» и «Выбор тем студентом» будут созданы два выражения ЛСА, которые будут составлены в соответствии с матрицей покрытия. Для выбранного на этапе анализа БП будут созданы две матрицы покрытия соответственно. Матрицы покрытия представлены в таблицах 1.8. и 1.9.

Таблица 1.8. Матрица покрытия для БП «Подготовка тем КР для приказа»

А1

А2

А3

К

Н

P1

А1

P2

А2

P3

А3

K

Таблица 1.9. Матрица покрытия для вложенного БП «Выбор тем студентом»

А1

А2

А3

К

Н

P1

P2

А1

P3

А2

P3

А3

K

На основе построенной матрицы покрытия создается выражение ЛСА. Для БП «Подготовка тем КР для приказа» ЛСА выглядит следующим образом:

Н p1^1 щ^4 v1 A1 p2^2 щ^4 v2 A2 p3^3 щ^4 v3 A3 ^4 v4 К

Для БП «Выбор темы студентами» ЛСА выглядит следующим образом:

Н p1^1 p2^2 щ^4 v1 A1 p3^3 щ^4 v2 A2 p3^3 щ^4 v3 A3^4 v4 К.

Выражение ЛСА построено таким образом, что при выборе ресурсов для условий pn, если выбрана неверная комбинация ресурсов, то ход игры приведет к ошибке и игра закончится. Например, рассмотрим, ЛСА для БП «Подготовка тем КР для приказа»: после начала процесса игрок выбирает ресурсы, и если они не совпадает с комбинацией ресурсов условия p1, то происходит безусловный переход к концу алгоритма.

1.4 Усовершенствование моделей

Усовершенствование модели УБП

Совершенствование моделей начнется с добавления времени в модель УБП, так как УБП является основой для генерации УУБП. Добавление времени в описание БП было решено добавить для того, чтобы приблизить проведение ДИ к более реальным условиям. С добавлением времени в ДИ появляются такие понятия как реальное время, имитационное время и процессорное, которые необходимо учесть в подсистеме проведения [6].

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

1) Автоматическое вычисление атрибута «длительность» при условии одновременно заданных значений для атрибутов «дата начала» и «дата конца».

2) Автоматическое вычисление атрибута «дата конца» при одновременно заданных значениях для атрибутов «дата начала» и «длительность».

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

Необходимость введения и фиксации именно трёх атрибутов времени для операции обосновываются следующими причинами:

1) Атрибут "время начала операции" требуется в тех случаях, когда важно установить дату/время, в которые операция должна быть начата.

2) Введение атрибута "длительность операции" обусловлено наличием операций, в которых приоритетным является определённая длительность.

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

Так как атрибут «время» относится к операции, то задавать его было решено, в 3 специально выделенные ячейки, при этом, не создавая никаких дополнительных ресурсов. Схема варианта представлена на рисунке 1.11.

Рисунок 1.11. Схематичное представления описания операции в нотации УБП

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

Рисунок 1.12. Ресурсы операции «Отправить темы студентов» с учетом атрибутов времени

Операция А2 как было выяснено ранее, имеет вложенный БП активного ресурса «Выбор темы студентом», и для того, чтобы перейти на следующую операцию этот БП должен выполниться за время, указанное в операции «Отправить темы студентам», то есть за 7 дней. Соответственно для успешного прохождения на следующую операцию вся сумма длительности операций вложенного БП активного ресурса «Выбор темы студентом» должна быть меньше или равна 7 дням.

Также было выяснено что через вложенный БП «Выбор темы студентом», должно пройти n-ое количество студентов. Для того чтобы обеспечить эту возможность необходимо при создании активного ресурса дать возможность задавать требуемое количество. В соответствии с этим количеством и с учетом времени необходимо дать возможность прописать информацию о результатах выполнения каждого экземпляра. В соответствии с выбранным БП, где активным ресурсом выступает студент, предположим, что, если количество студентов равно 5, то для каждого студента необходимо прописать, за какое время была выполнена каждая операция вложенного БП. Структура и примерные данные представлены в таблице 1.10.

Таблица 1.10. Ресурс «Студент» с настраиваемыми атрибутами

Номер ресурса

Название ресурса

Дата начала

Длительность

Дата конца

1

Иванов Иван Иванович

10.09.2018

6 (дней)

16.09.2018

2

Петров Петр Петрович

09.09.2018

8 (дней)

17.09.2018

…

…

…

…

…

При выполнении активным ресурсом №1 операции, длительность которой 7 дней, ресурс успешно выполнит её и перейдет на следующую операцию, так как временные рамки выполнения операции и время, за которое студент выполнил эту операцию, совпадают. Ресурс №2 не перейдет на следующую операцию, так как временные рамки для выполнения операции не были соблюдены.

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

Усовершенствование модели УУБП

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

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

Рисунок 1.13. УБП «Выбор тем студентами»

В процессе выбора ресурсов игроком параллельно с правильностью выбора набора ресурсов будет проверяться время по следующим условиям (рассмотрим точку принятия решения №1). Для того чтобы перейти на одну из следующих операций (А21/А22), необходимо чтобы у активного ресурса:

· Дата начала операции была не раньше даты выполнения.

· Дата начала не должна быть больше конца операции.

· Дата начала выполнения активного ресурса с учетом длительности выполнения не должна быть больше, чем дата конца операции.

После перехода к следующей точке принятия решения активный ресурс действует по тому же принципу.

1.5 Разработка метамоделей

Для того чтобы описать потоки данных между объектами, было выбран способ построения метамоделей. В СКДИ существует 3 основные связанные между собой модели: «Карта операций», «Точка принятия решения», «Операция». «Карта операций» включает в себя потоки между такими объектами как точка принятия решения и операции. Модель предназначена для того, чтобы описать УУБП в виде последовательности, состоящей из точек принятия решения и операций. Метамодель «Карта операций» представлена на рисунке 1.14.

Рисунок 1.14. Метамодель "Карта операций"

Следующая метамодель «Точка принятия решения» отражает потоки данных на этапе, когда игрок выбирает ресурсы для перехода на следующую операцию. Данная метамодель описывает процесс выбора ресурсов игроком в точке принятия решения.

Метамодель «Точка принятия решения» представлена на рисунке 1.15.

Рисунок 1.15. Метамодель "Декомпозиция точки принятия решения"

Следующая метамодель описывает потоки внутри операции, а также описывает поведение активного ресурса внутри операции. Метамодель «Операция» представлена на рисунке 1.16.

Рисунок 1.16. Метамодель «Операция»

1.6 Определение требований к редактору

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

Функциональные требования, которые были предъявлены к прототипу редактора:

1. После запуска редактора должно открыться окно, которое содержит рабочую область и панель с элементами необходимыми для построения УБП. Элементы, находящиеся на панели, должны быть перетаскиваемыми на рабочую область, где строится модель УБП.

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

3. Для элемента «Операция» должна иметься возможность задавать время, описывать ресурсы и переход на окно, где описываются операции активного ресурса, при условии, что он есть.

4. Заданные временные параметры должны быть изменяемыми.

5. При описании ресурсов должно открываться окно, которое содержит панель элементов и рабочую область, на которой при открытии окна уже находится блок, с операцией, для которой нужно описать ресурсы.

6. Необходимо позволить добавлять, удалять и редактировать ресурсы.

7. Каждая операция, имеющая активный ресурс, должна иметь описания вложенного БП активного ресурса. При открытии окна для описания БП Активного ресурса должно открываться окно аналогично окну, где описывается основной БП, имеющий рабочую область и панель элементов.

8. Модель УБП активного ресурса должна быть редактируемой.

9. Каждая операция вложенного БП активного ресурса должна иметь возможность описать ресурсы, которые входят в операцию.

10. Ресурсы, заданные к операции, должны быть редактируемыми.

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

12. После описания БП или БП активного ресурса на основе построенного УБП должна строиться модель УУБП, которая также должна редактироваться.

13. На основе построенной модели должна генерироваться матрица покрытия ЛСА и непосредственно выражение, которые должны иметь редактируемую форму.

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

Рисунок 1.17. Диаграмма вариантов использования (Use Case)

Сопоставим функциональные требования с созданными прецедентами. Сопоставление представлено в таблице 1.11.

Таблица 1.11. Функциональное требование и прецедент

Функциональное требование

Прецедент

После запуска редактора должно открыться окно, которое содержит рабочую область и панель элементов с элементами необходимыми для построения УБП. Элементы, находящиеся на панели, должны быть перетаскиваемыми на рабочую область, где строится модель УБП.

Отобразить экран для построения УБП.

Отобразить элементы для описания последовательности операций УБП.

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

Редактировать модель УБП.

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

Отобразить форму для задания времени.

Заданные временные параметры должны иметь возможность изменяться.

Редактировать временные параметры.

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

Отобразить экран описания ресурсов операции.

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

Необходимо позволить добавлять, удалять и редактировать ресурсы.

Редактировать ресурсы операции.

Каждая операция, имеющая активный ресурс, должна иметь описания вложенного БП активного ресурса. При открытии окна для описания БП Активного ресурса должно открываться окно аналогично окну, где описывается основной БП, имеющий рабочую область и панель элементов.

Отобразить экран для построения УБП активного ресурса.

Отобразить элементы для описания последовательности операций УБП активного ресурса.

Модель УБП активного ресурса должна быть редактируемой.

Редактировать модель УБП активного ресурса.

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

Отобразить экран описания ресурсов операции активного ресурса.

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

Ресурсы описанные операции должны иметь возможность к редактированию.

Редактировать ресурсы операции активного ресурса.

Каждая операция должна иметь возможность задать временные рамки и редактировать его.

Отобразить форму для задания времени.

Редактировать временные параметры.

После описания БП или БП активного ресурса на основе построенного УБП должна строиться модель УУБП, которая также должна редактироваться.

Сгенерировать УУБП.

Отобразить экран с сгенерированным УУБП.

Отобразить панель элементов УУБП.

Редактировать модель УУБП.

На основе построенной модели должна генерироваться матрица покрытия ЛСА и выражение. Также иметь возможность к редактированию.

Сгенерировать ЛСА.

Отобразить экран с сгенерированной ЛСА.

Редактировать ЛСА.

Подробное описание прецедентов представлено в таблице 1.12. и в приложении Б.

Таблица 1.12. Описание прецедентов

Прецедент

Отобразить экран для построения УБП

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

Выводит на экран окно, в котором есть панель элементов и рабочая область для построения модели.

Актеры

Проектировщик

Предусловия

Наличие описания рабочего БП.

Основной

поток

Решение о создании модели УБП на основе рабочего БП.

Запуск программы.

Отображение рабочей областью и элементов панели для рисования модели.

На панели отображается кнопка «Сгенерировать УУБП»

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

-

Постусловия

Открыто окно браузера, где можно построить УБП.

Точки расширения

Редактировать модель УБП.

Сгенерировать УУБП.

Отобразить экран описания ресурсов операции.

Редактировать временные параметры.

Отобразить экран для построения УБП активного ресурса.

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

1.7 Выбор инструментов для разработки

В определении актуальности данной работы стоит разработка web-приложения, которое будет представлять прототип редактора для информационной системы проектирования и проведения деловых игр. Для того чтобы создать разработать web-приложение, которое состоит из 2 частей: front-end и back-end, были выбраны языки программирования, соответствующие целям и особенностям разработки. В частности, для написания front-end было решено оперировать таким языком разработки как JavaScript в связи с тем, что данный язык является доступным и популярным среди web-разработчиков инструментом. Это определяет его использование в данной работе, поскольку с точки зрения перспективы дальнейшего развития интерфейса данной программы, использование JavaScript позволит снизить риски, связанные с уникальностью компетенций, требуемых для доработки информационной системы.

При создании back-end, то есть программно-аппаратной стороны интерфейса, web-разработчики, обычно применяют скриптовый язык программирования PHP. Однако в рамках данной работы будет использоваться язык C#, что обуславливается рядом факторов [14, 15]. Прежде всего, язык C# позволит ускорить работу разрабатываемого приложения, поскольку код компилируется при первом же обращении. Также важно отметить, что язык C# поддерживает XML, что даёт возможность обозначить структуру кода при помощи разметочных символов. Кроме того, говоря о необходимости обеспечения безопасности данных и снижения их уязвимости для внешних атак, можно заключить, что инструмент C# является более надёжным. Это подкрепляется статистикой, предоставленной лабораторией W3Techs, экспертами в области анализа использования различных технологий в Интернете: на текущий момент порядка 78,9% сайтов написаны на PHP, и большинство взломов в сети Интернет (около 71% на 2017 год) происходит ввиду недочётов в скриптах PHP [18]. В конце 2018 года был прекращён выпуск обновлений безопасности для PHP версий 5.x, что неизбежно привело к ещё более существенному снижению уровня защищённости Интернет-ресурсов, использующих PHP [17]. Последним аргументом в пользу C# является наличие механизма обработки ошибок, который предоставляет разработчику полный листинг компилятора с описанием ошибки, что в свою очередь позволяет более оперативно решать возникшие в ходе разработки проблемы. Для разработки web-приложения будет использоваться среда разработки Visual Studio от Microsoft, поддерживающая работу с C#. деловой игра редактор интерфейс

Для того чтобы развернуть базу данных (далее - БД), была выбрана платформа Azure от Microsoft, которая предоставляется возможность создать БД и подключить ее к Visual Studio для непосредственного внесения, изъятия, редактирования и сохранения данных, а также редактировать структуру через MS SQL Server. В дополнение к сказанному выше, решающим фактором выбора Azure было то, что данная платформа предоставляет возможность развернуть БД и обеспечить доступ к работе с ней для нескольких людей единовременно, что являлось необходимым условием для синхронизации и передачи данных из подсистемы проектирования в подсистему проведения.

2. Проектирование редактора

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

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

Связь между сущностями можно классифицировать по 4 типам:

1) Один к одному.

2) Один ко многим.

3) Многие к одному.

4) Многие ко многим.

ER-диаграмма построена таким образом, чтобы хранить все необходимые данные для подсистемы проектирования и проведения деловых игр, и представлена на рисунке 2.1.

Рисунок 2.1. ER-диаграмма (концептуальная модель БД)

В таблице 2.1. описаны таблицы БД в соответствии с особенностями среды, в которой планируется создание БД:

Таблица 2.1. Даталогическая модель

Сущность

Атрибут

Тип данных

Наименование поля

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

(BusinessProcess)

Код бизнес-процесса

uniqueidentifier

primaryKey

Код

nvarchar(255)

Code

Наименование БП

nvarchar(255)

Name

ЛСА

nvarchar(255)

LSA

Операции

(Operation)

Код операции

uniqueidentifier

primaryKey

Код бизнес-процесса

uniqueidentifier

BusinessProcess

Код

nvarchar(255)

Code

Название

nvarchar(255)

Name

Длительность

int

Duration

Ресурсы в операции

(ResourceInOperation)

Код связки ресурса и операции

uniqueidentifier

primaryKey

Код ресурса

uniqueidentifier

Resource

Код операции

uniqueidentifier

Operation

Ресурсы

(Resource)

Код ресурса

uniqueidentifier

primaryKey

Код

nvarchar(255)

Code

Название

nvarchar(255)

Name

Число

int

Amount

Код типа ресурса

uniqueidentifier

ResourceType

Типы ресурсов

(ResourceType)

 ...

Страница:


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

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

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