РАЗРАБОТКА МОДЕЛИ АВТОМАТИЗИРОВАННОЙ ПРОЦЕДУРЫ ГЕНЕРАЦИИ ПРОТОКОЛОВ О СДАЧЕ КАНДИДАТСКИХ ЭКЗАМЕНОВ

DEVELOPMENT OF A MODEL OF AN AUTOMATED PROCEDURE FOR GENERATING PROTOCOLS ON PASSING CANDIDATE EXAMS

Oksana Rozhkova

Senior Lecturer, Department of Information Technology and Computer Systems, MSTU «STANKIN»,

Russia, Moscow

Dmitry Rozhkov

Teacher, Department of Information Technology and Computer Systems, MSTU «STANKIN»,

Russia, Moscow

АННОТАЦИЯ

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

ABSTRACT

The article presents the results of the development of a model of an automated procedure for generating protocols for candidate exams. The requirements for the system are given. According to the formulated requirements, the system was modeled under various interaction conditions.

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

Keywords: modeling, automated procedure, protocol on passing candidate's exams, postgraduate studies.

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

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

Для решения данной задачи необходимо выбрать программное средство. Был проведен сравнительный анализ существующих решений, позволяющих автоматизировать учет, хранение, обработку и анализ информации об основных процессах вуза (таблица 1), где значения 0-5 вообще не реализованы или недостаточно реализованы, 6-10 требуют несущественных доработок или реализованы полностью.

Таблица 1.

Сравнительный анализ программных средств

Рассмотренные программные решения не удовлетворяют всем критериям. Таким образом, было принято решение разработать собственную систему, удовлетворяющую поставленным требованиям

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

Программный продукт должен предоставлять сотруднику следующий функционал:

• выбор шаблона документа;
• выбор базы данных;
• навигация по элементам базы данных, в том числе поиск информации по содержимому записей;
• выделение для дальнейшей обработки всех данных или их части;
• возможность склонения ФИО в родительный падеж согласно правилам русского языка;
• выбор места сохранения обработанных данных.

Одно из требований к программному продукту – графический пользовательский интерфейс, который будет включать в себя:

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

Основываясь на требованиях, на унифицированном языке моделирования UML (Unified Modeling Language) были сформулированы модели, описывающие и характеризующие систему.

С помощью диаграммы прецедентов отображены функциональные возможности системы (рисунок 1.)

Рисунок 1. Диаграмма прецедентов

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

Актёр или исполнитель – роль, которую пользователь играет по отношению к системе. Актёром может являться сущность за пределами системы.

Вариант использования – это последовательность действий, которые система может выполнять в процессе взаимодействия с актёрами. Отдельный вариант использования обозначается на диаграмме эллипсом.

В языке UML имеется несколько стандартных видов отношений между актёрами и вариантами использования:

1. Ассоциации (сплошная линия).
2. Включение (пунктирная линия с подписью «include» и со стрелкой, направленной от базового варианта использования к включаемому варианту использования).
3. Расширение (пунктирная линия с подписью «extend» и со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования).

Включение («include») в UML – это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем.

Расширение («extend») определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.

В данном случае актёр – пользователь, который взаимодействует с системой. Для пользователя характерны следующие прецеденты:

1. Выбрать шаблон документа – выбор образца, по которому система будет обрабатывать данные.
2. Выбрать базу данных – прецедент определяет данные, потенциально подлежащие дальнейшей обработке.

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

2.2. Сгенерировать протоколы в выбранную директорию – последовательность действий пользователя, после выполнения которых системой будут сгенерированы выходные данные. Является расширением прецедента «Выбрать базу данных».

2.2.1. Выделить необходимые записи БД – выбор конкретных данных для обработки системой. Прецедент является включаемым в прецедент «Сгенерировать протоколы в выбранную директорию».

3. Отфильтровать список записей БД – сортировка данных в соответствии с запросом пользователя.
4. Включить/выключить режим склонения ФИО – прецедент изменяет режим работы системы, что влияет на выходные данные.
5. Посмотреть руководство пользователя – прецедент, помогающий пользователю работать с системой.

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

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

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

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

Список литературы:

1. 1С: Университет. Описание: [сайт] – URL: https://solutions.1c.ru/catalog/university (дата обращения: 25.12.2023). – Текст: электронный.
2. ЭДО и СЭД: система электронного документооборота «Этлас»: [сайт] – URL: https://atlas-soft.ru/products/atlas-docflow/ (дата обращения: 25.12.2023). – Текст: электронный.
3. Этлас – обзор, отзывы, аналоги, альтернативы: [сайт] – URL: https://www.doc-online.ru/tool/2770/ (дата обращения: 25.12.2023). – Текст: электронный.