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

Актеры

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

Предусловия

Модель непустая, в нее были добавлены элементы либо она была загружена из базы данных

Основной

поток

Проектировщик нажимает на кнопку "Сохранить" и выбирает имя модели для сохранения

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

Если модель ранее уже была сохранена, то проектировщик не выбирает имя сохранения

Постусловия

Модель сохранена в базу данных

Прецедент

Загрузить модель из базы данных

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

Прецедент дает возможность загрузить любую создаваемую модель из базы данных

Актеры

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

Предусловия

Модель непустая, в нее были добавлены элементы либо она была загружена из базы данных

Основной

поток

Проектировщик нажимает на кнопку "Загрузить", открывается окно выбора файла, и проектировщик находит ранее сохраненную модель

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

Если в рабочей области уже содержится модель, то отображается диалоговое окно для сохранения текущей модели перед загрузкой новой, в результате которого либо вызывается прецедент "Сохранить модель в базу данных", либо текущая модель не сохраняется, либо происходит отмена загрузки новой модели

Постусловия

Модель загружена из базы данных

Исходя из описания прецедентов, выделим действия в основном и альтернативном потоках прецедентов, на основе которых можно будет создать диаграммы активности. Описание этих действий находится в таблице 2.4:

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

Прецедент	Состояние вида деятельности
Отобразить рабочий экран УБП	Отобразить рабочую область УБП Отобразить панель элементов УБП Отобразить список атрибутов модели УБП
Редактировать модель УБП	Добавить элемент Удалить элемент Переместить элемент Изменить размер элемента
Отобразить экран редактирования ресурсов	Отобразить рабочую область ресурсов Отобразить палитру ресурсов Отобразить панель ранее созданных ресурсов
Редактировать модель ресурсов	Добавить элемент Удалить элемент Переместить элемент Изменить размер элемента
Сгенерировать модель УУБП	Генерация модели УУБП Отобразить окно загрузки Автоматический переход на рабочий экран УУБП
Отобразить рабочий экран УУБП	Отобразить рабочую область УУБП Отобразить панель элементов УУБП Отобразить список атрибутов модели УУБП
Редактировать модель УБП	Добавить элемент Удалить элемент Переместить элемент Изменить размер элемента
Сгенерировать ЛСА	Генерация ЛСА Отображение окна прогресса Автоматический переход на экран редактирования ЛСА
Отобразить экран редактирования ЛСА	Отобразить матрицу ЛСА Отобразить строку ЛСА
Редактировать выражение ЛСА	Изменить содержание строки ЛСА в текстовом поле
Сохранить модель в базу данных	Нажатие на кнопку "Сохранить" Сохранение модели Выбор имени модели для сохранения, если модель ранее еще не была сохранена
Загрузить модель из базы данных	Нажатие на кнопку "Загрузить" Отображение окна выбора файла Загрузка модели Отображение диалогового окна для сохранения текущей модели перед загрузкой новой, в результате которого либо вызывается прецедент "Сохранить модель в базу данных", либо текущая модель не сохраняется, либо происходит отмена загрузки новой модели

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

Рисунок 2.3. Диаграмма активности создания моделей УБП и ресурсов.

Редактирование элементов диаграммы включает изменения ее содержания внешнего вида. При этом, в первом случае пользователь имеет возможность создавать или удалять элементы, а второй случай подразумевает изменение положения и размера элементов. Диаграммы активности изменения содержания и внешнего вида диаграмм УБП, а также самого прецедента редактирования представлены на рисунках 2.4-2.6:



Рисунок 2.4. Диаграмма активности редактирования диаграммы УБП.

Рисунок 2.5. Диаграмма активности редактирования содержания диаграммы УБП.

Рисунок 2.6. Диаграмма активности редактирования внешнего вида диаграммы УБП.

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

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

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

Рисунок 2.8. Диаграмма активности рабочего экрана УУБП.



На основе созданной модели УУБП пользователь может сгенерировать ЛСА, для чего на панели задач отображается соответствующая кнопка, подобно тому, как это было с генерацией модели УУБП. Таким же образом, в процессе генерации отображается окно загрузки, а по завершении автоматически открывается экран редактирования ЛСА. Соответствующая диаграмма активности представлена на рисунке 2.9:

Рисунок 2.9. Диаграмма активности генерации ЛСА.

Как только ЛСА сгенерирована начинается прецедент ее редактирования. Он включает отображение матрицы ЛСА и редактируемого поля с самой строкой автомата. Диаграмма активности изображена на рисунке 2.10:

Рисунок 2.10. Диаграмма активности редактирования ЛСА.

Взаимодействие с базой данных описывают прецеденты сохранения и загрузки моделей. Для сохранения модели необходимо ввести ее название и нажать кнопку "Сохранить", либо просто нажать кнопку, если модель уже была сохранена ранее. Диаграмма активности сохранения модели представлена на рисунке 2.11:

Рисунок 2.11. Диаграмма активности сохранения.

Для загрузки модели необходимо нажать кнопку "Загрузить", сохранить текущую модель, если она непустая, и выбрать наименование загружаемой модели. Диаграмма активности загрузки модели изображена на рисунке 2.12:

Рисунок 2.12. Диаграмма активности загрузки.

Перепроектирование модели ресурсов операций

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

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

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

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

Инфологическая модель

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

Информационный;

Финансовый;

Трудовой;

Оборудование;

Товар;

Услуга;

Контрагент.

Помимо вида ресурсы также подразделяются на категории и имеют признак обязательности (см. п. 2.6). Наконец, точка принятия решений служит основой для формирования модели сцены деловой игры. Данная модель описывает имеющиеся к выбору игрока ресурсы в момент принятия решения и определяет их внешний вид и расположение. Модель сцены будет использоваться в подсистеме проведения деловой игры. Общий список информационных сущностей и их атрибутов представлен в таблице 2.5:

Таблица 2.5. Инфологическая модель базы данных

Сущность	Атрибуты
Бизнес-процесс	Код Название Цель
Операция	Код Название Длительность Номер в бизнес-процессе
Точка принятия решения	Код Название
Модель сцены	Код Название Точка принятия решения
Модель экрана	Код Название Модель сцены
Информационный ресурс	Код Название Дата создания Документ Категория Является обязательным
Финансовый ресурс	Код Название Сумма Валюта Категория Является обязательным
Трудовой ресурс	Код ФИО Должность Зарплата в час Категория Является обязательным
Оборудование	Код Название Стоимость аренды Состояние Категория Является обязательным
Товар	Код Название Стоимость Количество Единицы измерения Категория Является обязательным
Услуга	Код Название Стоимость в час Длительность Категория Является обязательным
Контрагент	Код ФИО Адрес Номер телефона Адрес электронной почты Категория Является обязательным

Атрибуты Валюта, Должность, Единица измерения и Категория ресурса целесообразно выделить в справочники (таблица 2.6):



Таблица 2.6. Справочники базы данных

Справочник	Атрибуты
Валюта	Код Название
Должность	Код Название
Единица измерения	Код Название
Категория ресурса	Код Название

Для представления отношений между объектами построим диаграмму "Сущность-связь". Диаграмма представлена на рисунке 2.13:

Рисунок 2.13. Диаграмма отношений информационных объектов.

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

2.3 Бизнес-процесс и Операция

Операция и Ресурс.

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

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

Для связи модели сцены с бизнес-процессом, код модели будет добавлен в таблицу точки принятия решений. В таблице 2.7 находится описание всех таблиц базы данных и типов атрибутов в общем виде:

Таблица 2.7. Даталогическая модель базы данных

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

Графическое представление даталогической модели находится на рисунке 2.14:

Рисунок 2.14. Даталогическая модель базы данных.

Как и в предыдущей версии визуального редактора, в качестве сервера баз данных будет использоваться MS SQL Server. Физическая схема базы данных изображена на рисунке 2.15:

Рисунок 2.15. Схема базы данных в MS SQL Server.

2.4 Перепроектирование алгоритма формирования карты операций

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

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

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

Рисунок 2.16. Алгоритм формирования карты операций в состоянии "как есть".



Вычислим приблизительную сложность данного алгоритма. Для каждой из N ветвей операция создания ветви на схеме вызывается N-I раз, где I лежит в промежутке от 1 до N_1. Иными словами, при N операций имеем N! вызовов метода создания ветки, что совпадает с числом сценариев, генерируемых при N операций (см. п. 1.6.2). Таким образом, алгоритм формирования карты операций по прежней схеме имеет факториальную сложность, что в очередной раз подтверждает неприменимость существующего механизма при проектировании деловых игр.

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

Вычислим приблизительную сложность нового алгоритма. Теперь для каждой из N операций N-I раз создается элемент "Ошибка", а не целая ветвь

сценария. Количество создаваемых элементов можно посчитать по формуле:

,

где N - это число операций в процессе.

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

Рисунок 2.17. Алгоритм формирования карты операций в состоянии "как должно быть".

2.5 Перепроектирование алгоритма формирования ЛСА

В предыдущей версии редактора БП выражение ЛСА строится на основе матрицы ЛСА, которая, в свою очередь, получается из модели УУБП. В качестве строк и столбцов выступают точки принятия решений, а на их пересечении располагаются операции, выполнение которых ведет из одной точки решения в другую. Кроме того, имеется столбец "Конец" для обозначения того, какие операции завершают выполнение бизнес-процесса. Например, для УУБП, состоящего из двух операций, матрица ЛСА выглядит следующим образом (таблица 2.8):

Таблица 2.8. Матрица ЛСА

	ТПР 1	ТПР 2	ТПР3	Конец
ТПР 1		Операция 1	Операция 2
ТПР 2				Операция 2
ТПР 3				Операция 1

Выражение ЛСА, генерируемое на основе данной матрицы выглядит следующим образом: v0 S1 ^1 ^2 v1 S2 ^K v2 S3 ^K.

Реализованный алгоритм имеет несколько недостатков. Во-первых, генерируемая схема некорректна с точки зрения языка ЛСА (см. п. 1.4). В ней отсутствуют операторы начала и конца процесса, управляющее воздействие и безусловный переход. Во-вторых, выражение ЛСА не соответствует формируемой матрице, так как в ней содержатся только пути перехода между точками принятия решений, но не то, какие операции при этом выполняются. В-третьих, в процессе генерации сценария отсутствует привязка к ресурсам, что делает невозможным его использование в деловой игре.

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

Таким образом, в строках и столбцах матрицы должны быть операции и элементы начала и конца процесса. В ячейках же должны располагаться наборы условий, проверяемых в точке принятия решения, которая находится между элементами в соответствующих строке и столбце. Матрица ЛСА для простого УУБП, состоящего из двух операций в новой модели представлена в таблице 2.9:

Таблица 2.9. Новая матрица ЛСА

	Операция 1	Операция 2	Конец
Начало	Условие 1 - истинно		Условие 1 - ложно
Операция 1		Условие 2 - истинно
Операция 2			Безусловный переход

Следует заметить, что в данном примере переход в конец процесса из начала возможен, так как при ложном значении условия 1 возникает ошибка, которая ведет к концу процесса. Ложное значение условия 2 не предусмотрено новой моделью УУБП (см. п. 2.2), так как в последней ТПР не остается ресурсов, выбор которых мог бы привести к ошибке. Переводя значения ячеек на язык ЛСА, получаем следующий вид матрицы (таблица 2.10):

Таблица 2.10. Новая матрица ЛСА на языке ЛСА

	А1	А2	К
Н	Р1
А1		Р2
А2			щ

Выражение ЛСА, генерируемое на основе данной матрицы будет выглядеть следующим образом: Н Р1^1 А1 Р2^1 А2 щ^1 v1К.

Стоит заметить, что приведенный формат выражения имеет вид, который понятен проектировщику. В памяти компьютера же ЛСА хранится в машинно-ориентированной форме, не имеющей операторов перехода, поскольку последние содержатся в условных операторах в виде ссылок на управляющие воздействия. Блок-схемы алгоритмов генерации матрицы и выражения ЛСА изображены на рисунке 2.18:



Рисунок 2.18. Алгоритмы формирования матрицы и строки ЛСА.

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



3. Разработка программного модуля

Разработка программного модуля будет вестись в среде разработки Visual Studio 2015 на языке C#, так как данные средства использовались при создании прототипов автоматной и операционной моделей.

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

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

В прежней версии редакторов много пространства на формах была отведено для отступов и интервалов между элементами, что сокращало размеры рабочих областей для диаграмм. Интерфейс редактора бизнес-процессов и редактора ресурсов предоставлены на рисунках 3.1 и 3.2 соответственно:

Рисунок 3.1. Интерфейс прежней версии редактора БП.



Рисунок 3.2. Интерфейс прежней версии редактора ресурсов.

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

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

На формах будут удалены лишние отступы между элементами, что позволит использовать максимум отведенного рабочего пространства для построения моделей. Визуальное представление нового интерфейса для моделей БП и ресурсов изображено на рисунках 3.3 и 3.4:

Рисунок 3.3. Интерфейс новой версии редактора БП.

Рисунок 3.4. Интерфейс модели ресурсов новой версии редактора БП.

Для создания и редактирования атрибутов ресурсов будет использоваться отдельная форма. Пример окна для информационного ресурса представлен на рисунке 3.5:



Рисунок 3.5. Интерфейс создания и редактирования информационного ресурса.

Форма редактирования ЛСА будет аналогична прежней с незначительными цветовыми изменениями. Справа отображается матрица ЛСА, а слева - текстовое поле с выражением ЛСА. Внешний вид формы изображен на рисунке 3.6:

Рисунок 3.6. Форма редактирования ЛСА.

3.2 Интеграция бизнес-логики

Процесс интеграции функций прототипов затрагивает в первую очередь их архитектурное содержание. Как было описано в главе 1, процесс, выполняемый редактором ресурсов, является подпроцессом работы редактора бизнес-процессов. Поэтому основой для итогового приложения будет являться именно редактор бизнес-процессов. Классы приложения, относящиеся к ресурсам необходимо перенести в редактор бизнес-процессов. К таковым относятся абстрактный класс BaseResource и его наследники, реализующие логику всех необходимых для деловой игры ресурсов. На рисунке 3.7 изображены классы, добавляемые в редактор бизнес-процессов из редактора ресурсов:

Рисунок 3.7. Диаграмма классов ресурсов.

В связи с изменениями, внесенными в модель учебного унифицированного бизнес-процесса, в классы этой модели необходимо добавить элемент "Ошибка". Данный объект будет представлен абстрактным классом Error, который будут наследовать классы грубой и негрубой ошибок - TolerableError и GrossError соответственно. Данная схема необходима для обеспечения возможности дальнейшего создания негрубых ошибок, которое не входит в задачи данной работы. Класс Error, как и все остальные элементы модели, будет наследовать набор базовых атрибутов класса BaseLogic, а также иметь метод MakeError для формирования ошибки во время генерации модели УУБП на основе списка операций и ресурсов для текущей точки принятия решений.

Помимо этого, для реализации модели ресурсов операций, в классы OperationRBP и OperationTBP следует добавить свойство для доступа к ресурсам операций и методы для управления ими. Для этого создадим интерфейс IOperation, в котором определим необходимые атрибуты. Вышеупомянутые классы будут реализовывать данный интерфейс. Получившийся набор классов, управляющих логикой моделей УБП и УУБП, изображен на рисунке 3.8:

Рисунок 3.8. Диаграмма классов моделей.

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

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

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

private void DrawBranch(DesignerItem root, List<DesignerItem> operationPool)

if (operationPool.Count != 0)

DesignerItem dmp = this.AttachDMP(root, operationPool);

DesignerItem operation = this.CreateItem(Canvas.GetTop(dmp) + 140, this.GlobalOffsetX);

operation.Content = this.GetOperationTBPContent();

operation.BoundLogicItem = new OperationTBP(operationPool[0].BoundLogicItem.ID, operation.ID);

operation.BoundLogicItem.Name = operationPool[0].BoundLogicItem.Name;

operation.dispName = operation.BoundLogicItem.Name;

operation.Tag = "OperationTBP";

TBPDesigner.Children.Add(operation);

TBPDesigner.SetConnectorDecoratorTemplate(operation);

this.DrawConnection(dmp.ID, operation.ID);

operationPool.RemoveAt(0);

for (int i = 0; i < operationPool.Count; i++)

DesignerItem error = this.CreateItem(Canvas.GetTop(dmp) + 140, this.GlobalOffsetX + 140 * (i + 1));

error.Content = this.GetErrorContent();

error.BoundLogicItem = new GrossError(Guid.NewGuid(), error.ID);

error.Tag = "ErrorTBP";

TBPDesigner.Children.Add(error);

TBPDesigner.SetConnectorDecoratorTemplate(error);

this.DrawConnection(dmp.ID, error.ID);

AttachEndTBP(error);

this.DrawBranch(operation, operationPool);

Для реализации защиты от переполнения стека (см. п. 2.8) запустим алгоритм на 250 операциях УБП. Результаты запусков находятся в таблице 3.1:

Таблица 3.1. Результаты запусков алгоритма

Номер запуска	Номер операции, вызвавший исключение
1	213
2	207
3	218
4	213
5	205

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

Реализация алгоритмов генерации матрицы и строки ЛСА

Для реализации ранее спроектированных алгоритмов будут созданы специальные методы GenerateMatrix и GenerateALS, которые будут вызываться функцией Generate_ALS, подписанной на соответствующую команду ленты задач редактора. Для создания матрицы будут дополнительно созданы методы добавления условных и безусловных операторов. Первый будет иметь два входных параметра: порядковый номер операции и логическое значение, отвечающее за отрицание (истина - обыкновенный оператор, ложь - отрицание оператора). Метод создания безусловного оператора параметров иметь не будет. Исходный код генерации матрицы представлен далее:

private DataTable GenerateMatrix() {

var matrix = CreateEmptyMatrix(n);

for (int i = 1; i < n - 2; i++)

matrix.Columns[i][i - 1] = AddConditionalOperator(i, true);

matrix.Columns[n - 1][i - 1] = AddConditionalOperator(i, false);

matrix.Columns[n - 2][n - 2] = AddConditionalOperator(n, true);

matrix.Columns[n - 1][n - 1] = AddUnconditionalOperator();

return matrix; }

Для генерации самого выражения ЛСА на основе матрицы будут дополнительно созданы методы StartJumpOperator и EndJumpOperator, предназначенные для добавления в строку операторов начала и конца перехода соответственно. Исходный код метода генерации ЛСА представлен ниже:

private string GenerateALS(DataTable matrix)

string als = string.Empty;

for (int i = 0; i < n; i++)

als += matrix.Columns[0][i];

als += StartJumpOperator();

als += matrix.Columns[i + 1][i];

als += EndJumpOperator() + "K";

return als;

3.3 Проектирование деловой игры на примере

Проведем проектирование деловой игры на основе простого процесса, состоящего из двух операций. В первую операцию добавим информационный ресурс под названием "Информация". Модель УБП для процесса и модель ресурсов для первой операции представлены на рисунке 3.9. Во вторую операцию добавим финансовый ресурс. Как видно на рисунке 3.10, на панели ранее созданных ресурсов уже присутствует информационный ресурс из первой операции.

Рисунок 3.9. Модель ресурсов первой операции УБП.

Рисунок 3.10. Модель ресурсов второй операции УБП.



На основе созданной модели УБП сгенерируем модель УУБП. Затем сразу сгенерируем ЛСА. Визуальные представления сгенерированных моделей изображены на рисунках 3.11-3.12:

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

Рисунок 3.12. Сгенерированные матрица и строка ЛСА.

В данной главе работы приведены разработка интерфейса нового редактора бизнес-процессов и интеграция функций имеющих прототипов, а также реализованы ранее перепроектированные алгоритмы генерации УУБП и ЛСА. Разработанный функционал программного модуля продемонстрирован на примере простого бизнес_процесса.

программный учебный деловой игра



Заключение

На сегодняшний день в любой профессиональной деятельности большое значение имеет уровень компетенций специалистов. Деловые игры являются эффективным активным методом развития компетенций. Для автоматизации предметно-независимой разработки деловых игр на кафедре информационных технологий в бизнесе НИУ ВШЭ-Пермь была разработана концепция студии компетентностных деловых игр. Данная работа была выполнена в рамках комплексной задачи разработки подсистемы проектирования деловой игры для СКДИ. Основный целью работы являлось разработка программного модуля подсистемы проектирования.

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

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



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

1. Gonzбlez, J. & Wagenaar, R. (2003). Tuning educational structures in Europe. Informe final. Proyecto Piloto-Fase 1 (ANECA. 2003).

2. Харитонова Е.В. Об определении понятий "компетентность" и "компетенция" // Успехи современного естествознания. - 2007. - № 3 - С. 67_68 (URL: www.rae.ru/use/?section=content&op=show_article&article_id=7778001; дата обращения: 23.11.2015).

3. Мединцева И. П. Компетентностный подход в образовании [Текст] / И. П. Мединцева // Педагогическое мастерство: материалы II междунар. науч. конф. (г. Москва, декабрь 2012 г.). -- М.: Буки-Веди, 2012.

4. Викентьева, О.Л. Концепция студии компетентностных деловых игр / О.Л. Викентьева, А.И. Дерябин, Л.В. Шестакова // Современные проблемы науки и образования. - 2013. - № 2; (URL: http://www.science-education.ru/108-8746; дата обращения: 24.11.2015).

5. Аngels Fitу-Bertran, Ana Beatriz Hernбndez-Lara, Enric Serradell-Lуpez. (2013, July). Comparing student competences in a face-to-face and online business game. Computers in Human Behavior (30), 452-459.

6. Ковалевич, И. А. Управление человеческими ресурсами : учеб. пособие / И. А. Ковалевич, В. Т. Ковалевич. - Красноярск : Сибирский федеральный ун-т, 2011. - 210 с. - ISBN 978-5-7638-2237-3.

7. Активные методы обучения: рекомендации по разработке и применению: Учебно-методическое пособие / Зарукина Е.В., Н. А. Логинова, М. М. Новик. / СПб.: СПбГИЭУ, 2010. - 59 с.

8. В. Д. Балин, В. К. Гайда, В. К. Гербачевский и др.. Практикум по общей, экспериментальной и прикладной психологии / Под общей ред. А. А. Крылова, С. А. Маничева. -- 2-е изд., доп. и перераб. -- СПб.: Питер. -- 560 с.: ил. -- (Серия "Практикум по психологии"), 2003.

9. Викентьева, О.Л. Подсистема проектирования информационной системы для проведения деловых игр / О.Л. Викентьева, А.И. Дерябин, Д.Д. Кожевников, Н.В. Красилич, Л.В. Шестакова // Технологии разработки информационных систем: сборник статей международной научно-практической конференции. - 2015. с. 27-32; (URL: https://www.hse.ru/pubs/share/direct/document/159158244; дата обращения: 27.03.2016).

10. Галкин Г. Мифы и парадигмы интеграции приложений // Intelligent Enterprise. - 2004. - № 12-13, (101); (URL: http://www.iemag.ru/analitics/detail. php?ID=16050; дата обращения: 15.04.2016).

11. Франгулова Е.В. Классификация подходов к интеграции и интероперабельности информационных систем // Вестник Астраханского государственного технического университета. Серия: Управление, вычислительная техника и информатика. - 2010. - № 2; (URL: http://cyberleninka.ru/ article/n/klassifikatsiya-podhodov-k-integratsii-i-interoperabelnosti-informatsionnyh-sistem; дата обращения: 16.04.2016).

Размещено на Allbest.ru

...