Составления расписания занятий в высшем учебном заведении

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

К настоящему времени разработан ряд компьютерных программ для автоматического составления расписания. CyberMatrix Class Sheduler может использоваться как одним преподавателем, для составления личного расписания, так и диспетчерским отделом для составления расписания занятий всего учебного заведения. В программе присутствуют средства фильтрации и поиска; ее недостатком является наличие только английского интерфейса, что однозначно вызовет затруднения при работе. «Моделедром – Расписание» в качестве исходных данных использует список дисциплин, список учебных групп и учебную нагрузку каждой группы; позволяет печатать полученные таблицы расписаний с разбивкой по листам. К сожалению, демо-версия не дает возможность оценить уровень программы и целесообразность ее приобретения за немалую цену. Расписание ПРО предназначена для составления расписания занятий любых учебных заведений в ручном и автоматическом режиме; в любой момент в расписание можно внести изменения, распечатать его или экспортировать таблицу в MS-Excel. Программа позволяет вести списки кабинетов, преподавателей, предметов, групп (классов), задавать связи между ними и нагрузку по предметам; есть возможность задать рабочее время индивидуально для преподавателя и приоритет предметов в расписании. Предусматривается как ручное составление расписания (с отслеживанием заданных ограничений), так и автоматический расчет – с дальнейшей «ручной» корректировкой (так как не существует строгих алгоритмов составления расписания, в автоматическом режиме предлагаются лишь возможные варианты автоматического расчета). Является универсальным средством составления расписаний, однако достаточно сложна и неудобна в обращении. «Ректор» также позволяет составлять расписания для любого учебного заведения и предусматривает ручной и автоматический режимы работы; составленное расписание может быть выведено в файл форматов Word 97/2000, Excel 97/2000, HTML 4.0 с разбиением на страницы. Однако, несмотря на заявленную универсальность, данная программа реально подготовлена для работы исключительно в средних учебных заведениях: все термины («урок», «ученики» и т.д.) «жестко зашиты» в программу и не предусматривают модификации. Таким образом, изучив имеющиеся программы, можно сделать вывод, что число разработанных программ относительно невелико, а качество их выполнения далеко от совершенства. Лидером в этой области является ООО «Дигси», создавшее программу «Расписание Про» и представившее условно-бесплатную (ShareWare) версию.

Логичным выводом является решение спроектировать собственную систему для автоматизированного составления расписания. Основные требования к системе формулируются следующим образом:

– осуществлять как «ручное» составление расписания, так и автоматическое с возможностью дальнейшей «ручной» корректировки;

– предполагать возможность внесения изменений в составленное расписание (замена предметов, преподавателей, аудиторий);

– производить учет выполнения нагрузки;

– распечатывать расписания по курсам, группам, кафедрам и другую отчетность (вывод в Excel).

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

Из-за достаточной сложности проектируемой информационной системы обычный структурный подход не подходит, так как при нем основой системы является алгоритм – последовательность действий по решению задач. Запись процесса составления расписания в виде алгоритма нецелесообразна, и мы применим объектно-ориентированный подход. Информационная система в таком случае будет представлять собой совокупность взаимосвязанных объектов.

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

1. Объектно-ориентированный анализ предметной области: определение ключевых абстракций, идентификация классов и объектов.

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

3. Программная реализация разработанной модели.

Первый этап включает анализ действий по составлению расписания, выделение активных и пассивных классов (объектов). Актером (активным объектом) здесь является диспетчер, пассивными объектами – таблицы, предоставляемые кафедрами согласно учебным планам, и аудиторный фонд.

На втором этапе создается информационная модель проектируемой системы, для чего используется унифицированный язык моделирования UML. Сначала формулируются требования к разрабатываемой системе, определяются функции, которые она должна реализовать, и задачи, которые она должна решать. На основе этих данных формируется диаграмма вариантов использования (рис.113).

 

 

 

Рисунок 113 – Диаграмма вариантов использования

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

Далее строится структурно-логическая схема системы в виде диаграммы классов (рис.114).

 

 

Рисунок 114 – Диаграмма классов

 

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

Мы предполагаем существование в системе следующих классов: аудиторный фонд, студенты, нагрузка, расписание, управляющее окно и таблица. Класс «Таблица» является абстрактным: он не имеет экземпляров и связан с классами «Аудиторный фонд», «Студенты» и «Нагрузка» отношением наследования. Стереотип «control» класса «Управляющее окно» указывает на то, что этот класс отвечает за координацию действий других классов.

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

 

 

 

Рисунок 115 – Диаграмма коопераций

 

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

 

 

 

Рисунок 116 – Диаграмма последовательности

 

На диаграмме видно, что инициатором взаимодействия является диспетчер-составитель, который обладает фокусом управления на протяжении всей работы системы, постоянно контролируя ее деятельность. С объектов «Нагрузка», «Аудиторный фонд» и «Студенты» собирается соответствующая информация путем перехода фокуса управления от управляющего окна к соответствующему объекту и обратно. Когда собрана вся необходимая информация, создается объект «Расписание», получающий временный фокус управления.

Диаграмма состояний описывает процесс изменения состояний системы или ее подсистемы при реализации всех вариантов использования. При этом изменение состояний отдельных элементов системы может быть вызвано внешними воздействиями со стороны других элементов или извне системы. Именно для описания реакции системы на подобные внешние воздействия и используются диаграммы состояний (рис. 117).

 

 

 

Рисунок 11 7 – Диаграмма состояний

 

Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Каждое состояние на этой диаграмме соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами – переходы от одного состояния действия к другому. Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний (рис. 118).

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

 

 

 

 

Рисунок 118 – Диаграмма деятельности

 

Спроектированная информационная система для автоматизации процесса составления расписания занятий была реализована в среде Borland Delphi [14-19].

 

 

 

Рисунок 119 – Диаграмма компонентов

 

Рассчитанный коэффициент экономической эффективности системы оказался равным 3,43; срок окупаемости затрат на внедрение информационной системы составил 0,29 лет.