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

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

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

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

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

DJANGO предоставляет быструю и удобную ORM по работе с СУБД. Имеет мощный встроенный шаблонизатор, для написания клиентской части системы.

Также имеется большой практический опыт работы с данным языком программирования и Framework'ом

Framework постоянно обновляется и дорабатывается сообществом и имеет отличную документацию. [6]

Выбор СУБД

В качестве кандидатов рассматриваются СУБД MySQL, Postgres и SQLite в качестве временной БД для DEV-разработки (каждая из данных СУБД является бесплатной и свободно распространяемой):

СУБД MySQL обычно используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Основные положительные стороны MySQL:

· Многопоточность. Поддержка нескольких одновременных запросов.

· Оптимизация связей с присоединением многих данных за один проход.

· Записи фиксированной и переменной длины.

· ODBC драйвер в комплекте с исходником

· Гибкая система привилегий и паролей.

· До 16 ключей в таблице. Каждый ключ может иметь до 15 полей.

· Поддержка ключевых полей и специальных полей в операторе.

· Поддержка чисел длинной от 1 до 4 байт (ints, float, double, fixed), строк переменной длины и меток времени.

· Основанная на потоках, быстрая система памяти.

· Все данные хранятся в формате ISO8859_1.

· Все операции работы со строками не обращают внимания на регистр символов в обрабатываемых строках.

· Псевдонимы применимы как к таблицам, так и к отдельным колонкам в таблице.

· Все поля имеют значение по умолчанию. Можно использовать на любом подмножестве полей.

· Легкость управления таблицей, включая добавление и удаление ключей и полей.

СУБД PostgreSQL является самой профессиональной из всех трех представленных СУБД для выбора. Она максимально на сколько возможно соответствует стандартам SQL. В Postgres стараются полностью применять ANSI/ISO SQL стандарты при выходах новых версий.

От других СУБД PostgreSQL отличается поддержкой объектно-ориентированного или реляционного подхода к БД. Например, полная поддержка надежных транзакций, то есть атомарность, последовательность, изоляционность, прочность (Atomicity, Consistency, Isolation, Durability (ACID).)

Основные плюсы PostgresSQL:

· Открытое ПО максимально соответствующее стандарту SQL

· Полная и нативная совместимость с сервером приложений DJANGO

· Большое сообщество по поддержке и разработке данный СУБД с полной и хорошей официальной документацией.

· Расширения - возможность расширения функционала с помощью своих хранимых процедур.

· Объектность - Postgres это не только реляционная СУДБ, но также и объектно-ориентированная.

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

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

Как результат, рассмотрев все положительные и отрицательные стороны представленных СУБД, решено использовать «Postgres». Ключевыми положительными сторонами при выборе были следующие:

· максимальное соответствие стандартам SQL92,98,2003;

· полная поддержка ACID;

· масштабируемость и работа с большими объемами данных;

· большое количество встроенных типов данных. В том числе JSONB и геоданные;

· максимальная совместимость с DJANGO ORM;

· отличная и доступная документация;

· надежная система фиксации изменений в журналах транзакций;

· наилучшая скорость работы при чтении, обновлении и вставки данных;

· возможность написания процедур для выделения единиц повторяющейся логики. [5] [20]

3.3 Реализация базы данных

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

Всю структуру БД условно можно разделить на три части:

1. Справочники - справочная информация по каждой школе (предметы, учебные кабинеты, расписание уроков, профили учителей и так далее).

2. Сущность расписание - представлено в виде эталонного расписания и текущего (актуального) расписания на каждый учебный день. Также вспомогательные сущности, отвечающие за учебные нагрузку для каждого учебного периода - четверть.

3. Сущности статистик для возможного прогнозирования и более успешной оптимизации расписания в будущем.

Выделим основные сущности предметной области и их атрибуты.

Сущности приложения справочники:

1. Сущность SchoolClass - содержит информацию по учебному классу в школе:

· id - уникальный идентификатор;

· class_name - название класса.

2. Сущность Classroom - хранит информацию по учебным кабинетам в школе:

· id - уникальный идентификатор;

· room_name - название учебного кабинета.

3. Сущность Subject - хранит информацию по учебным предметам преподаваемых в школе:

· id - уникальный идентификатор;

· sub_name - название предмета;

· sub_short_name - краткое название предмета;

· weight - коэффициент веса учебного предмета;

· subject_type - тип учебного предмета.

4. Сущность classrooms_subjects является таблицей связкой между сущностями classrooms и subjects, содержит информацию о том в какой аудитории может проводится тот или иной предмет.

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

· id - уникальный идентификатор;

· id_classroom - внешний ключ на сущность учебный кабинет;

· id_subject - внешний ключ на сущность учебный кабинет.

Сущности Classrooms и Subjects имеют связь «Многое-ко-Многим».

5. Сущность SchoolClassGroup - содержит информацию по делению классов на подгруппы по определенным предметам:

· Id - уникальный идентификатор;

· School_class - внешний ключ на сущность учебный класс;

· Subject - внешний ключ на сущность учебный предмет;

· Group_name - название группы для деления.

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

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

· Id - уникальный идентификатор;

· Last_name - фамилия учителя;

· First_name - имя учителя;

· Father_name - отчество учителя.

7. Сущность teachers_subjects (учителя - предметы) - служит для хранения информации о том какой предмет может вести учитель (профиль):

· Id - уникальный идентификатор;

· Id_teacher - ссылка на сущность учитель;

· Id_subject - ссылка на сущность учебный предмет.

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

Сущности приложения учебное расписание:

1. Сущность SchoolQuarter - содержит информацию по учебным четвертям в школе:

· Id - уникальный идентификатор

· Quarter_number - номер учебной четверти

· Start_date - начало учебной четверти

· End_date - конец учебной четверти

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

· Id - уникальный идентификатор

· School_quarter - ссылка на сущность учебная четверть

· School_class - ссылка на сущность учебный класс

· Sub_class - ссылка на сущность группа учебного класса

· Subject_week - учебная неделя (первая, вторая или каждую неделю)

· Week_lesson_count - уроков в неделю

· Total_lesson_count - уроков всего за учебный период

3. Сущность LessonTime - хранит справочную информацию по времени уроков расписания:

· Id - уникальный идентификатор

· Begin_time - время начала урока

· End_time - время окончания урока

· Rest_time - время перерыва после урока

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

· Id - уникальный идентификатор

· Lesson_date - время урока

· School_class - ссылка на учебный класс

· Subject - ссылка на учебный предмет

· Classroom - ссылка на учебный кабинет

· Teacher - ссылка на учителя

· LessonStatus - статус урока

· Description - краткая дополнительная информация по уроку.

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

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

3.4 Реализация узлов графа целостности расписания

Для реализации графа целостности выделен базовый интерфейс - BaseNode, который содержит метод «analyze» задача этого метода проанализировать урок или какую-либо часть расписания, в зависимости от переданного аргумента «event_info».

Реализация узла нагрузки

Для реализации данного узла создан класс «LoadNode». Данный класс принимает на вход урок из расписания, получает предмет и текущую учебную четверть. На основе этой информации получает учебный план для класса. Агрегирует уже проведенные уроки для класса и предмета в рамках учебного периода, сравнивает с количеством указанном в учебном плане и на основе этой информации формируется структура «verdict» с типом ошибки, ее описанием и дополнительной информацией специфичной для каждой ошибки, которая может помочь при формировании ответа на слой клиента или же для формирования запроса к другому узлу графа:

· Если фактически уроков проведено меньше - устанавливает статус «NOT_MORE_LESSON_DONE».

· Если фактически уроков проведено больше - устанавливает статус «TO_MORE_LESSON_DONE».

· Далее узел проверяет количество отмененных уроков в расписании, если таковые имеются, то выставляет статус «HAVE_CANCELED_LESSONS».

После завершения анализа возвращает структуру «verdict».

Реализация узла нагрузки приведена в ПРИЛОЖЕНИИ 4.

Реализация узла согласования

Для реализации данного узла создан класс «CoordinationNode». Данный класс принимает на вход уже отредактированный урок из расписания. По данному уроку ищется исходный урок для сравнения. Под сравнением понимается:

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

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

· Отличие преподавателя, который может проводить урок в заданное время у другого класса

Таким образом, узел анализирует информацию по времени проведения урока, учебному кабинету и учителю. На основе этой информации формируется структура «verdict» с типом ошибки, ее описанием и дополнительной информацией специфичной для каждой ошибки, которая может помочь при формировании ответа на слой клиента или же для формирования запроса к другому узлу графа:

· Если урок переносится на время, в которое уже идет другой урок - выставляется статус «ALREADY_STAY_LESSON».

· Если проведение урока переносится в другой учебный кабинет, в котором уже идет другой урок, то в ответе выставляется статус «ALREADY_BUSY_CLASSROOM».

· Если проведение урока назначается учителю, который в данный момент уже ведет урок у другого класса, то устанавливается статус «ALREADY_BUSY_TEACHER».

После завершения анализа узел возвращает ответ - «verdict». Реализация узла согласования приведена в ПРИЛОЖЕНИИ 4.

Реализация узла приоритетов

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

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

Анализ для оптимизации расписания узел проводит в несколько шагов:

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

· Поиск подряд идущих уроков одинакового типа по сложности, не более двух

· Комбинирование уроков с гуманитарными и техническими уклонами

· Расстановка первых уроков по принципу наиболее простых предметов

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

3.5 Этапы внедрения разрабатываемой системы

В настоящий момент система находится в активной стадии разработки прототипа полноценного работающего web-приложения.

Программная разработка является полностью бесплатной и распространяется на правах разработчика.

Средства для внедрения системы такого рода будут минимальными, так как все что требуется от учебного заведения (школы) это персональный компьютер для завуча, которым он уже вероятнее всего располагает, доступ к сети интернет и установленный web-browser.

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

· Список учителей школы

· Список учебных кабинетов

· Список учебных предметов

· Расписание учебных звонков

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

· Внесение плана нагрузки по классам и предметам на учебную четверть

Для более быстрого заполнения справочной информации планируется добавить формы загрузки из файлов excel формата *.xlsx.

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

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

Заключение

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

В соответствии с целью поставлены следующие задачи:

· Расписание должно составляться на основе учебного плана, для каждого класса (для нескольких классов, входящих в параллель могут быть различия в учебном плане).

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

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

· Поиск в расписании по следующим параметрам: на любой заданный день, по заданному классу, преподавателю, предмету и так далее.

· Возможность переноса / учета того что урок не состоялся по какой-либо причине.

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

· Система должна иметь возможность попытки предложения автоматического разрешения конфликтов расписания.

· Предоставление отчетов и статистик по расписанию в графическом и текстовом виде.

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

Причины для этого были следующие:

· Необходимо чтобы система работала и была доступна 24\7, то есть в любое время к ней можно было получить доступ.

· Требования для внедрения такой системы резко снижаются - все что необходимо это компьютер или телефон с возможностью выхода в интернет при помощи браузера.

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

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

Предметом исследования является школьное учебное расписание.

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

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

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

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

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

Разработана архитектуры системы поддержки принятия решений на базе web-интерфейса для пользователей.

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

В ходе всей разработки информационной системы происходило активное общение и анализ требований завуча одной из СОШ. Рассматривались имеющиеся методологии и текущие способы при составлении расписания в школе. Завучи проявили большую заинтересованность к системе такого рода.

С началом нового учебного года, планируется внедрение прототипа системы в СОШ №1 города Вытегры, Вологодской области и в СОШ Белоусово, Вытегорского района.

Список использованных источников

1. Наука составлять расписание [Электронный ресурс]: инф.-справ. система. - Режим доступа: http://zdd.1september.ru/article.php? ID=200600805.

2. Автоматизированное составление расписания занятий в школе [Электронный ресурс]: инф.-справ. система. - Режим доступа: http://pedsovet.su/publ/44-1-0-850.

3. Рекомендации по составлению школьного расписания [Электронный ресурс]: инф.-справ. система. - Режим доступа: http://www.menobr.ru/materials/370/5139.

4. Виды Тестирования Программного Обеспечения [Электронный ресурс]: инф.-справ. система. - Режим доступа: http://www.protesting.ru/testing/testtypes.html.

5. Анализ СУБД [Электронный ресурс]: инф.-справ. система. - Режим доступа: http://www.loginovprojects.ru/index.php? page=whyfirebird#minmem.

6. Руководство по программированию на Python [Электронный ресурс]: офиц. сайт. - Режим доступа: https://msdn.microsoft.com/ru-ru/library/67ef8sbd.aspx.

7. Документация FireBird [Электронный ресурс]: офиц. сайт. - Режим доступа: http://www.firebirdsql.org/manual/ru/.

8. Теория и технология программирования [Электронный ресурс]: инф.-справ. система. - Режим доступа: http://it.fitib.altstu.ru/neud/cs/index.php? action=show&show=100.

9. Составление учебного расписания [Электронный ресурс]: инф.-справ. система. - Режим доступа: http://www.rae.ru/snt/? section=content&op=show_article&article_id=2736.

10. Симанов, А.Н. Информационная система принятия решений при создании, контроле, оптимизации и выявлении проблемных мест в школьном учебном расписании / А.Н. Симанов, Е.Н. Давыдова // Вузовская наука региону материалы 24 Всероссийской научной конференции. Вологодский государственный университет. 2016. С. 134-136

11. Симанов, А.Н. Проблемы автоматизации, формализации и оптимизации учебного расписания в школах / А.Н. Симанов // Материалы 27 Международной конференции «Современные информационные технологии в образовании» 28 июня Троицк - Москва. 2016. С. 205-208

12. Симанов, А.Н. Информационная система принятия решений при формировании школьного расписания / А.Н. Симанов // Приоритетные направления развития науки и образования: материалы XI Междунар. науч.-практ. конф. (Чебоксары, 27 нояб. 2016 г.). В 2 т. Т. 1 / редкол.: О.Н. Широков [и др.]. - Чебоксары: ЦНС «Интерактив плюс», 2016. - №4 (11). - С. 224-226. - ISSN 2411-9652.

13. Симанов, А.Н. Проблемы автоматизации и формализации учебного расписания в школах / А.Н. Симанов // Приоритетные направления развития науки и образования: материалы XI Междунар. науч.-практ. конф. (Чебоксары, 27 нояб. 2016 г.). В 2 т. Т. 1 / редкол.: О.Н. Широков [и др.]. - Чебоксары: ЦНС «Интерактив плюс», 2016. - №4 (11). - С. 224-226. - ISSN 2411-9652.

14. Костюк, В.И. Использование алгоритмов последовательной обработки для составления расписаний / В.И. Костюк, Х.О. Мартинес, В.В. Зорин // Вопросы создания АСУ ВУЗ. М.: НИИВШ, 1976. - С. 3-5.

15. Маслов, М.Г. Эвристический алгоритм решения задачи составления расписания учебных занятий в вузе / М.Г. Маслов // Математические методы в технике и технологиях: Сб. трудов XV Международной научной конференции. В 10-и т. 2-4 июня 2002 г. - Тамбов, 2002. - Т.9. - С. 86-88.

16. Сидорин, А.Б. Методы автоматизации составления расписания занятий [Электронный ресурс]: инф.-справ. система. - Режим доступа: http:// cyberleninka.ru/article/n/metody-avtomatizatsii-sostavleniya-raspisaniya-zanyatiy-chast-1-klassicheskie-metody.

17. Клеванский, Н.Н. Анализ результатов автоматического формирования расписания занятий ВУЗ'а [Текст] / Н.Н. Клеванский, Е.А. Макарцова // XII Международная конференция выставка «Информационные технологии в образовании». Часть IV. - М.: МИФИ, 2002. - С. 193.

18. Программа «НИКА-Люкс» [Электронный ресурс]: офиц. сайт - Режим доступа: http://www.nikasoft.ru/.

19. Ресурс «schoodle» [Электронный ресурс]: офиц. сайт. - Режим доступа: http:// schoodle.ru/.

20. Анализ систем управления базами данных [Электронный ресурс]: инф.-справ. система. - Режим доступа: http://devacademy.ru/posts/sqlite-vs-mysql-vs-postgresql.

21. Исходный код разработанной системы [Электронный ресурс]: инф.-справ. система. - Режим доступа: https://github.com/nemodeveloper/nemodev_platform/tree/schedule.

Приложение 1

Физическая реализация базы данных

Сущности приложения справочники:

CREATE TABLE «CATALOGS_CLASS_ROOMS»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«ROOM_NAME» VARCHAR(20) NOT NULL UNIQUE

);

CREATE TABLE «CATALOGS_SCHOOL_CLASS»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«CLASS_NAME» VARCHAR(15) NOT NULL UNIQUE

);

CREATE TABLE «CATALOGS_SCHOOL_CLASS_GROUP»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«GROUP_NAME» VARCHAR(20) NOT NULL,

«SCHOOL_CLASS_ID» INTEGER NOT NULL

);

CREATE TABLE «CATALOGS_SUBJECTS»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«SUB_NAME» VARCHAR(25) NOT NULL UNIQUE,

«SUB_SHORT_NAME» VARCHAR(12) NOT NULL,

«WEIGHT» INTEGER NOT NULL,

«SUBJECT_TYPE» VARCHAR(7) NOT NULL

);

CREATE TABLE «CATALOGS_SUBJECTS_CLASS_ROOMS»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«SUBJECT_ID» INTEGER NOT NULL,

«CLASSROOM_ID» INTEGER NOT NULL

);

CREATE TABLE «CATALOGS_TEACHERS»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«LAST_NAME» VARCHAR(20) NOT NULL,

«FIRST_NAME» VARCHAR(15) NOT NULL,

«FATHER_NAME» VARCHAR(15) NOT NULL

);

CREATE TABLE «CATALOGS_TEACHERS_SUBJECTS»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«TEACHER_ID» INTEGER NOT NULL,

«SUBJECT_ID» INTEGER NOT NULL

);

ALTER TABLE «CATALOGS_SCHOOL_CLASS_GROUP» ADD COLUMN «SUBJECT_ID» INTEGER NOT NULL;

CREATE INDEX «CATALOGS_CLASS_ROOMS_ROOM_NAME_59B6B199_LIKE» ON «CATALOGS_CLASS_ROOMS» («ROOM_NAME» VARCHAR_PATTERN_OPS);

CREATE INDEX «CATALOGS_SCHOOL_CLASS_CLASS_NAME_61E17398_LIKE» ON «CATALOGS_SCHOOL_CLASS» («CLASS_NAME» VARCHAR_PATTERN_OPS);

ALTER TABLE «CATALOGS_SCHOOL_CLASS_GROUP» ADD CONSTRAINT «CATALOGS_SCHOOL_CLAS_SCHOOL_CLASS_ID_E4EAFEDC_FK_CATALOGS_» FOREIGN KEY («SCHOOL_CLASS_ID») REFERENCES «CATALOGS_SCHOOL_CLASS» («ID») DEFERRABLE INITIALLY DEFERRED;

CREATE INDEX «CATALOGS_SCHOOL_CLASS_GROUP_SCHOOL_CLASS_ID_E4EAFEDC» ON «CATALOGS_SCHOOL_CLASS_GROUP» («SCHOOL_CLASS_ID»);

CREATE INDEX «CATALOGS_SUBJECTS_SUB_NAME_5D78B76B_LIKE» ON «CATALOGS_SUBJECTS» («SUB_NAME» VARCHAR_PATTERN_OPS);

ALTER TABLE «CATALOGS_SUBJECTS_CLASS_ROOMS» ADD CONSTRAINT «CATALOGS_SUBJECTS_CL_SUBJECT_ID_CBB692B7_FK_CATALOGS_» FOREIGN KEY («SUBJECT_ID») REFERENCES «CATALOGS_SUBJECTS» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «CATALOGS_SUBJECTS_CLASS_ROOMS» ADD CONSTRAINT «CATALOGS_SUBJECTS_CL_CLASSROOM_ID_AF48C9BE_FK_CATALOGS_» FOREIGN KEY («CLASSROOM_ID») REFERENCES «CATALOGS_CLASS_ROOMS» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «CATALOGS_SUBJECTS_CLASS_ROOMS» ADD CONSTRAINT «CATALOGS_SUBJECTS_CLASS__SUBJECT_ID_CLASSROOM_ID_B717C904_UNIQ» UNIQUE («SUBJECT_ID», «CLASSROOM_ID»);

CREATE INDEX «CATALOGS_SUBJECTS_CLASS_ROOMS_SUBJECT_ID_CBB692B7» ON «CATALOGS_SUBJECTS_CLASS_ROOMS» («SUBJECT_ID»);

CREATE INDEX «CATALOGS_SUBJECTS_CLASS_ROOMS_CLASSROOM_ID_AF48C9BE» ON «CATALOGS_SUBJECTS_CLASS_ROOMS» («CLASSROOM_ID»);

ALTER TABLE «CATALOGS_TEACHERS_SUBJECTS» ADD CONSTRAINT «CATALOGS_TEACHERS_SU_TEACHER_ID_01DCE3F6_FK_CATALOGS_» FOREIGN KEY («TEACHER_ID») REFERENCES «CATALOGS_TEACHERS» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «CATALOGS_TEACHERS_SUBJECTS» ADD CONSTRAINT «CATALOGS_TEACHERS_SU_SUBJECT_ID_17250C35_FK_CATALOGS_» FOREIGN KEY («SUBJECT_ID») REFERENCES «CATALOGS_SUBJECTS» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «CATALOGS_TEACHERS_SUBJECTS» ADD CONSTRAINT «CATALOGS_TEACHERS_SUBJECTS_TEACHER_ID_SUBJECT_ID_56131CE0_UNIQ» UNIQUE («TEACHER_ID», «SUBJECT_ID»);

CREATE INDEX «CATALOGS_TEACHERS_SUBJECTS_TEACHER_ID_01DCE3F6» ON «CATALOGS_TEACHERS_SUBJECTS» («TEACHER_ID»);

CREATE INDEX «CATALOGS_TEACHERS_SUBJECTS_SUBJECT_ID_17250C35» ON «CATALOGS_TEACHERS_SUBJECTS» («SUBJECT_ID»);

CREATE INDEX «CATALOGS_SCHOOL_CLASS_GROUP_SUBJECT_ID_0F42F879» ON «CATALOGS_SCHOOL_CLASS_GROUP» («SUBJECT_ID»);

ALTER TABLE «CATALOGS_SCHOOL_CLASS_GROUP» ADD CONSTRAINT «CATALOGS_SCHOOL_CLAS_SUBJECT_ID_0F42F879_FK_CATALOGS_» FOREIGN KEY («SUBJECT_ID») REFERENCES «CATALOGS_SUBJECTS» («ID») DEFERRABLE INITIALLY DEFERRED;

COMMIT;

Сущности приложения учебное расписание:

BEGIN;

CREATE TABLE «CATALOGS_LESSON_TIME»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«BEGIN_TIME» TIME NOT NULL,

«END_TIME» TIME NOT NULL,

«REST_TIME» TIME NOT NULL

);

CREATE TABLE «SCHEDULE_LESSONS»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«LESSON_DATE» TIMESTAMP WITH TIME ZONE NOT NULL,

«LESSON_STATUS» VARCHAR(8) NOT NULL,

«DESCRIPTION» VARCHAR(100) NULL,

«CLASSROOM_ID» INTEGER NOT NULL,

«SCHOOL_CLASS_ID» INTEGER NOT NULL,

«SUBJECT_ID» INTEGER NOT NULL,

«TEACHER_ID» INTEGER NOT NULL

);

CREATE TABLE «SCHEDULE_WORK_PLAN»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«QUARTER_NUMBER» VARCHAR(1) NOT NULL,

«START_DATE» DATE NOT NULL,

«END_DATE» DATE NOT NULL

);

CREATE TABLE «SCHEDULE_WORK_PLAN»

(

«ID» SERIAL NOT NULL PRIMARY KEY,

«SUBJECT_PERIOD» VARCHAR(10) NOT NULL,

«WEEK_LESSON_COUNT» INTEGER NOT NULL,

«TOTAL_LESSON_COUNT» INTEGER NOT NULL,

«SCHOOL_CLASS_ID» INTEGER NOT NULL,

«SCHOOL_QUARTER_ID» INTEGER NOT NULL,

«SUB_CLASS_ID» INTEGER NOT NULL,

«SUBJECT_ID» INTEGER NOT NULL);

ALTER TABLE «SCHEDULE_LESSONS» ADD CONSTRAINT «SCHEDULE_LESSONS_CLASSROOM_ID_B6FDE1A7_FK_CATALOGS_» FOREIGN KEY («CLASSROOM_ID») REFERENCES «CATALOGS_CLASS_ROOMS» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «SCHEDULE_LESSONS» ADD CONSTRAINT «SCHEDULE_LESSONS_SCHOOL_CLASS_ID_70962FD8_FK_CATALOGS_» FOREIGN KEY («SCHOOL_CLASS_ID») REFERENCES «CATALOGS_SCHOOL_CLASS» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «SCHEDULE_LESSONS» ADD CONSTRAINT «SCHEDULE_LESSONS_SUBJECT_ID_FD324928_FK_CATALOGS_SUBJECTS_ID» FOREIGN KEY («SUBJECT_ID») REFERENCES «CATALOGS_SUBJECTS» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «SCHEDULE_LESSONS» ADD CONSTRAINT «SCHEDULE_LESSONS_TEACHER_ID_86AD7B5C_FK_CATALOGS_TEACHERS_ID» FOREIGN KEY («TEACHER_ID») REFERENCES «CATALOGS_TEACHERS» («ID») DEFERRABLE INITIALLY DEFERRED;

CREATE INDEX «SCHEDULE_LESSONS_CLASSROOM_ID_B6FDE1A7» ON «SCHEDULE_LESSONS» («CLASSROOM_ID»);

CREATE INDEX «SCHEDULE_LESSONS_SCHOOL_CLASS_ID_70962FD8» ON «SCHEDULE_LESSONS» («SCHOOL_CLASS_ID»);

CREATE INDEX «SCHEDULE_LESSONS_SUBJECT_ID_FD324928» ON «SCHEDULE_LESSONS» («SUBJECT_ID»);

CREATE INDEX «SCHEDULE_LESSONS_TEACHER_ID_86AD7B5C» ON «SCHEDULE_LESSONS» («TEACHER_ID»);

ALTER TABLE «SCHEDULE_WORK_PLAN» ADD CONSTRAINT «SCHEDULE_WORK_PLAN_SCHOOL_CLASS_ID_57B06E05_FK_CATALOGS_» FOREIGN KEY («SCHOOL_CLASS_ID») REFERENCES «CATALOGS_SCHOOL_CLASS» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «SCHEDULE_WORK_PLAN» ADD CONSTRAINT «SCHEDULE_WORK_PLAN_SCHOOL_QUARTER_ID_4CE8C6E0_FK_SCHEDULE_» FOREIGN KEY («SCHOOL_QUARTER_ID») REFERENCES «SCHEDULE_WORK_PLAN» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «SCHEDULE_WORK_PLAN» ADD CONSTRAINT «SCHEDULE_WORK_PLAN_SUB_CLASS_ID_E67106E5_FK_CATALOGS_» FOREIGN KEY («SUB_CLASS_ID») REFERENCES «CATALOGS_SCHOOL_CLASS_GROUP» («ID») DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE «SCHEDULE_WORK_PLAN» ADD CONSTRAINT «SCHEDULE_WORK_PLAN_SUBJECT_ID_1524D158_FK_CATALOGS_SUBJECTS_ID» FOREIGN KEY («SUBJECT_ID») REFERENCES «CATALOGS_SUBJECTS» («ID») DEFERRABLE INITIALLY DEFERRED;

CREATE INDEX «SCHEDULE_WORK_PLAN_SCHOOL_CLASS_ID_57B06E05» ON «SCHEDULE_WORK_PLAN» («SCHOOL_CLASS_ID»);

CREATE INDEX «SCHEDULE_WORK_PLAN_SCHOOL_QUARTER_ID_4CE8C6E0» ON «SCHEDULE_WORK_PLAN» («SCHOOL_QUARTER_ID»);

CREATE INDEX «SCHEDULE_WORK_PLAN_SUB_CLASS_ID_E67106E5» ON «SCHEDULE_WORK_PLAN» («SUB_CLASS_ID»);

CREATE INDEX «SCHEDULE_WORK_PLAN_SUBJECT_ID_1524D158» ON «SCHEDULE_WORK_PLAN» («SUBJECT_ID»);

COMMIT;

Приложение 2

Исходный код приложения

Базовый интерфейс узла графа целостности

class BaseNode(object):

def __init__(self):

super (BaseNode, self).__init__()

def analyze (self, event_info):

raise NotImplementedError ('Метод анализа расписания узлом')

# Узел нагрузки

class LoadNode(BaseNode):

# data - урок для анализа

def __init__(self, data):

super (LoadNode, self).__init__()

self.data = data

self.cur_quarter = self._get_current_quarter()

self.subject_name = self.data.subject.sub_name

# Получить текущий учебный период

def _get_current_quarter(self):

return SchoolQuarter.objects.filter (

start_date__gte=self.data.lesson_date.date,

end_date__lte=self.data.lesson_date.date

).first()

# Получить количество уроков по учебному плану

def _get_subject_count(self):

work_plan = WorkPlan.objects.filter (school_quarter=self.cur_quarter,

subject=self.data.subject,

school_class=self.data.school_class

).first()

return work_plan.total_lesson_count if work_plan else 0

# Получить фактическое проведенное количество уроков

def _get_current_subject_count(self):

return Lesson.objects.filter (subject=self.data.subject, school_class=self.data.school_class).count()

# Получить отмененные уроки

def _get_canceled_lessons(self):

return Lesson.objects.filter (subject=self.data.subject,

school_class=self.data.school_class,

lesson_status='CANCELED')

def _build_base_verdict(self):

return {

'type': «,

'errors': [],

}

def analyze (self, event_info):

verdict = self._build_base_verdict()

work_plan_subject_count = self._get_subject_count()

current_subject_count = self._get_current_subject_count()

not_done_count = work_plan_subject_count - current_subject_count

event_type = event_info['type']

verdict['type'] = event_type

if event_info in LESSON_EVENTS:

errors = verdict['errors']

base_kwargs = {

'plan_count': work_plan_subject_count,

'current_count': current_subject_count,

}

if not_done_count < 0:

errors.append (

NodeAnalyzeError('TO_MORE_LESSON_DONE',

'По предмету % s проведено больше предметов чем по учебному плану!'% self.subject_name,

**base_kwargs)

)

if not_done_count > 0:

errors.append (

NodeAnalyzeError('NOT_MORE_LESSON_DONE',

'По предмет % s проведено меньше уроков чем по учебному плану!'% self.subject_name,

**base_kwargs)

)

canceled_lessons = self._get_canceled_lessons()

if canceled_lessons:

base_kwargs ['canceled_lessons'] = canceled_lessons

errors.append (

NodeAnalyzeError('HAVE_CANCELED_LESSON',

'По предмету % s есть отмененные уроки!'% self.subject_name,

**base_kwargs)

)

else:

verdict['errors'].append (

NodeAnalyzeError('NOT_CORRECT_EVENT', 'Не корректное событие по работе с расписанием для узла нагрузки -%s'% event_type)

)

return verdict

# Узел согласования

class CoordinationNode(BaseNode):

NODE_EVENTS = (

'EDIT'

)

# data - сформированный урок после редактирования

def __init__(self, data):

super (CoordinationNode, self).__init__()

self.edit_lesson = data

self.base_lesson = Lesson.objects.get (id=self.edit_lesson.id)

def _build_base_verdict(self):

return {

'node': 'COORDINATION',

'type': «,

'errors': [],

}

# попытаться изменить время, кабинет, учителя, учебный кабинет, класс

def try_edit (self, verdict):

errors = verdict['errors']

# проверим смену начала урока

if self.edit_lesson.lesson_date!= self.base_lesson.lesson_date:

swap_lesson = Lesson.objects.filter (lesson_date=self.edit_lesson.lesson_date,

school_class=self.edit_lesson.school_class).first()

# Если есть урок сигнализируем об этом

if swap_lesson:

errors.append (

NodeAnalyzeError('ALREADY_STAY_LESSON',

'В указанное время уже назначен урок!',

**{'swap_lesson': swap_lesson})

)

# проверим коллизии учебных кабинетов

if self.edit_lesson.classroom!= self.base_lesson.classroom:

busy_lesson = Lesson.objects.filter (lesson_date=self.edit_lesson.lesson_date,

classroom=self.edit_lesson.classroom).first()

# Если нашли урок который проводится в том же кабинете и в то же время

if busy_lesson:

errors.append (

NodeAnalyzeError('ALREADY_BUSY_CLASSROOM',

'В выбранном кабинете уже проводится урок!',

**{'busy_lesson': busy_lesson})

)

# проверим коллизии учителей

if self.edit_lesson.teacher!= self.base_lesson.teacher:

busy_lesson = Lesson.objects.filter (lesson_date=self.edit_lesson.lesson_date,

teacher=self.edit_lesson.teacher).first()

# Если нашли преподавателя который уже ведет урок в это время

if busy_lesson:

errors.append (

NodeAnalyzeError('ALREADY_BUSY_TEACHER',

'В это время выбранный преподаватель уже ведет урок!',

**{'busy_lesson': busy_lesson})

)

def analyze (self, event_info):

verdict = self._build_base_verdict()

event_type = event_info['type']

verdict['type'] = event_type

if event_info in CoordinationNode.NODE_EVENTS:

if event_type == 'EDIT':

self.try_edit(verdict)

else:

verdict['errors'].append (

NodeAnalyzeError('NOT_CORRECT_EVENT',

'Не корректное событие по работе с расписанием для узла согласования -%s'% event_type)

)

return verdict

# Узел приоритетов

class PriorityNode(BaseNode):

NODE_EVENTS = (

'ANALYZE',

)

def __init__(self, start_date, end_date):

super (PriorityNode, self).__init__()

self.start_date = start_date

self.end_date = end_date

self.lessons = Lesson.objects.filter (start_date__gte=self.start_date,

start_date__lte=self.end_date)

self.aggr_lessons = {}

def _build_base_verdict(self):

return {

'node': 'PRIORITY',

'type': «,

'errors': [],

'lessons': []

}

def _aggregate_lessons(self):

for lesson in self.lessons:

date = lesson.lesson_date.date()

lessons_by_date = self.aggr_lessons[date]

if not lessons_by_date:

lessons_by_date = {}

self.aggr_lessons[date] = lessons_by_date

school_class = lesson.school_class

lessons_by_class = lessons_by_date [school_class]

if not lessons_by_class:

lessons_by_class = []

lessons_by_date [school_class] = lessons_by_class

lessons_by_class.append(lesson)

def _order_aggr_lessons(self):

# сортируем уроки по классам и времени

for lessons_by_date in self.aggr_lessons.values():

for lessons_by_class in lessons_by_date.values():

lessons_by_class.sort (key=itemgetter ('lesson_date'))

def __compare_lesson_for_weight (self, lef_lesson, right_lesson):

right_lesson_date = right_lesson.lesson_date

right_lesson.lesson_date = lef_lesson.lesson_date

verdict = CoordinationNode (right_lesson).analyze (event_info={'type': 'EDIT'})

right_lesson.lesson_date = right_lesson_date

return len (verdict['errors']) == 0

def __aggr_subject_by_weight (self, lessons):

lessons.sort (key=itemgetter ('subject.weight'),

function=self.__compare_lesson_for_weight)

return lessons

def __find_lesson_explicit_type (self, explicit_type, lessons):

return [lesson for lesson in lessons if lesson.subject.subject_type!= explicit_type]

def __swap_lessons (self, lesson, candidate_lessons):

lesson_date = lesson.lesson_date

for candidate in candidate_lessons:

lesson.lesson_date = candidate.lesson_date

verdict = CoordinationNode(lesson).analyze (event_info={'type': 'EDIT'})

if len (verdict['errors']) == 0:

candidate.lesson_date = lesson_date

break

def __aggr_subject_by_type (self, lessons, try_count):

if try_count > 1:

return lessons

cur_lesson_type = None

cur_type_reply = 1

end_index = 0

new_lessons = lessons

for lesson in lessons:

if cur_lesson_type == lesson.subject.subject_type:

cur_type_reply += 1

else:

cur_lesson_type = lesson.subject.subject_type

cur_type_reply = 1

if cur_type_reply == 2:

candidate_lessons = self.__find_lesson_explicit_type (cur_lesson_type, lessons)

self.__swap_lessons (lessons[end_index], candidate_lessons)

return self.__aggr_subject_by_type (new_lessons, try_count + 1)

return new_lessons

def _do_optimize(self):

for key_date, lessons_by_date in self.aggr_lessons.items():

for key_class, lessons_by_class in lessons_by_date.items():

optimize_lessons = self.__aggr_subject_by_weight (lessons_by_class)

optimize_lessons = self.__aggr_subject_by_type (optimize_lessons, 0)

lessons_by_date [key_class] = optimize_lessons

def analyze (self, event_info):

verdict = self._build_base_verdict()

event_type = event_info['type']

verdict['type'] = event_type

if event_info in PriorityNode.NODE_EVENTS:

# аггрегируем уроки по дням недели

self._aggregate_lessons()

self._order_aggr_lessons()

self._do_optimize()

verdict['lessons'] = self.aggr_lessons

else:

verdict['errors'].append (

NodeAnalyzeError('NOT_CORRECT_EVENT',

'Не корректное событие по работе с расписанием для узла согласования -%s'% event_type)

)

return verdict

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


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

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