Реферат: Автоматизированное рабочее место
Министерство образования РФ
Дальневосточныйгосударственный университет
Институтматематики и компьютерных наук
Кафедраинформатики
Автоматизированное рабочее место
«СЕССИЯ»
Дипломнаяработа
студенткигр. 256
КоноваловойД.Ю.
Руководитель:
ХрапченковИ.Ф.,
начальникОРПО
МГУ им.Невельского
Соруководитель:
КленинаН.В.,
доцент кафедрыинформатики
ИМиКН ДВГУ
Владивосток,2007
1. Содержание
1. Содержание
2. Введение
2.1. Глоссарий
2.2. Описание предметнойобласти
2.3. Неформальная постановказадачи
2.4. Обзор существующихрешений
2.4.1. Московский государственныйиндустриальный университет (МГИУ)
2.4.2. Проект «Naumen University»
2.4.3. МГТУ им. Н.Э. Баумана
2.4.4. Автоматизированнаяинформационная система «Электронный Деканат «ЭД++» РЭА им. Г. В. Плеханова
2.4.5. Система «Студент»,Санкт-Петербургский государственный университет
2.4.6. Выводы
3. Требования к окружению
3.1. Требования к аппаратномуобеспечению
3.2. Требования к программномуобеспечению
3.3. Требования к пользователям
4. Архитектура системы
5. Спецификация данных
5.1. Сущности системы
5.1.1. Семестр рабочего плана(WorkTerm)
5.1.2. Рабочий план (WorkPlan)
5.1.3. Сессия (Session)
5.1.4. Учебное поручение(TeacherPart)
5.1.5. Группа (Group)
5.1.6. Отчетность подисциплине (DisciplineControl)
5.1.7. Студент (Student)
5.1.8. Ведомость (ControlRegister)
5.1.9. Балл (Mark)
5.1.10. Оценка (Result)
5.2. Схема потоков данныхмежду подсистемами РИВСУУП
6. Функциональные требования
6.1. Авторизационная форма
6.2. Форма выбора факультета
6.3. Главная форма
6.4. Форма выбора сессии
6.5. Форма выбора учебнойкарточки
6.6. Форма учебной карточки
6.7. Форма просмотра спискаспециальностей
6.8. Форма просмотра отчетностейгруппы
6.9. Форма зачетно-экзаменационнойведомости
6.10. Автоматическое составлениепечатных документов на основе шаблонов
6.10.1. Компонентыядра РИВСУУП, используемые для экспорта документов в Word и Excel
6.11. Требования к интерфейсу
6.11.1. Визуальныекомпоненты ядра РИВСУУП
7. Проект
7.1. Структура БД
7.2. Модули и алгоритмы
7.2.1. Модули
7.2.2. Проект интерфейса
8. Реализация
8.1. Объем кода
8.2. Тестирование
Заключение
Список литературы
2. Введение
2.1. Глоссарий
Академическая группа – совокупность учащихся (возможно, неполная), обучающаясяпо рабочему учебному плану специальности или (например, для учащихся колледжа) какому-либодругому документу. Академическая группа студентов дневного отделения имеет общеерасписание
Аудитория – помещение, в котором в соответствии с расписанием могут проводитьсязанятия того или иного вида
Группа для занятий – совокупность учащихся, объединенных вместе для занятий(может быть: академическая группа, подгруппы или несколько академических групп,объединенных в поток)
Дисциплина – предусмотренная учебным планом и рабочим учебным планам, областьзнания, предназначенная для обязательного или факультативного изучения. Дисциплинаизучается студентами в виде нескольких последовательных разделов
Кафедра – подразделение, закрепленное за определенным факультетом, объединяющеепреподавателей и выполняющее учебное поручение кафедры. За кафедрой закреплен определенныйнабор дисциплин
Отчетность – экзамен, зачет, дифференцированный зачет, государственный экзамен,экзамен по рейтингу, комплексный экзамен, диплом, курсовая работа, курсовой проект
Планируемый преподаватель – человек, планируемый для выполнениячасти Учебного поручения кафедры
Подразделение – единица состава МГУ, характеризуемая набором штатных единици материальной базой
Поток – одна или несколько Академических групп, обучающихся по одномурабочему плану
Преподаватель — сотрудник МГУ, занимающий преподавательскую должность и имеющийучебную нагрузку
Рабочий учебный план специальности – набор дисциплин, их объем, формы проведенияи итогового контроля в соответствии с графиком учебного процесса для выполненияучебного плана специальности, с указанием кафедры
Семестр – период времени учебного года, на который составляются учебныепоручения
Сессия – часть учебного процесса, в течение которой студенты проходятитоговый контроль
Студент – человек, обучающийся в МГУ на любой (в т. ч. дистанционной)форме обучения
Учебное поручение кафедре – Построенные на базе Рабочего планаспециальности строки, объединяющие часы, даваемые каждой Группе для занятий
Учебное поручение преподавателям – связьУчебное поручение кафедре – Планируемый преподаватель. Документ, регламентирующийраспределение нагрузки на кафедру по преподавателям кафедры
Учебный год – период времени обучения, определяемый рабочим учебным планом
Учебный план специальности – набор дисциплин, групп дисциплин, ихобъем, формы проведения и итогового контроля, необходимые для подготовки специалистовзаданной специальности
Факультет – подразделение, отвечающее за подготовку учащихся по ряду рабочихпланов
2.2. Описание предметнойобласти
Отделом разработки программного обеспеченияМорского государственного университета им. Г.И. Невельского уже несколько лет ведетсяработа над «Распределённой информационно-вычислительной системой управления учебнымпроцессом и производственной деятельностью» (РИВСУ УППД) [[9]].
Система обеспечивает автоматизацию работыуправления кадров, управления делами, приемной комиссии, курсантского и студенческогоотдела кадров, учебно-методического управления, деканатов, кафедр и поддержку дистанционныхтехнологий образования. Обеспечивается взаимодействие РИВСУ с системой управленияфинансовой деятельностью, построенной на системе 1С- Предприятие.
РИВСУУП делится на подсистемы, каждаяиз которых содержит несколько АРМов (АРМ — автоматизированное рабочее место). Каждаяподсистема соответствует некоторому направлению работ, например, подсистема «Учебныепланы» позволяет готовить учебные планы в рамках планирования учебного процесса.Каждый АРМ подсистемы позволяет решать задачи определенного подразделения или конкретногосотрудника МГУ, например, АРМ «Редактор ГОС» подсистемы «Учебные планы» предназначендля занесения и редактирования государственных образовательных стандартов и используетсяв учебно-методическом управлении.
Центральной частью РИВСУ УППД являетсяподсистема планирования учебного процесса, автоматизирующая весь комплекс работпо составлению, передвижению и использованию государственных образовательных стандартов,графиков учебного процесса, учебных планов специальностей и годовых учебных планов,штатного расписания преподавательского состава и учебных поручений.
Подсистема АРМы Абитуриент Анкета Выходные формы Утилита администрирования Штатное расписание и кадры Редактор структуры подразделений Штатное расписание Назначения и перемещения Картотека Учебные планы Редактор ГОС Редактор учебных планов Редактор рабочих учебных планов Нагрузка и учебные поручения кафедр Параметры расчета Редактор нагрузки теоретического обучения Распределение практической нагрузки по кафедрам Редактор собственной нагрузки Занесение расчетно-графических и контрольных работ Выходные формы Учебные поручения Подсистема обеспечения безопасности Редактор прав пользователей Редактор системных объектов Деканат Сессия Курсантский и студенческий отдел кадров Курсантский и студенческий отдел кадров Паспортный стол Военно-учетный стол Финансово-экономическая служба КвартплатаЧто касается работы деканатов, то большаячасть их задач охватывается АРМом «Курсантский и студенческий отдел кадров». В частности,внесение анкетных данных учащихся и ведение различных документов (приказы о зачислении,о переводе на другой курс, о переводе на другой факультет, об отчислении и т.д.,выписки из приказов). Однако в РИВСУУП никак не отражены задачи деканата во времясессии:
· Ведение зачетно-экзаменационныхведомостей;
· Занесение в базу данныхрезультатов сдач экзаменов, зачетов, курсовых работ и т.д.
Вследствие этого возникают следующие проблемы:
· Отсутствие в базеотражения успеваемости студентов;
· Неправильное ведениедеканатами документов по сессии:
– Отсутствие единойформы ведомости;
– Отсутствие индивидуальныхведомостей.
· Значительные затратывремени на составление отчетных документов (сводных ведомостей и т.д.), а такжена подготовку документов к диплому.
· Как следствие человеческогофактора, большое количество ошибок в документах
Данные проблемы и будут решаться при разработкеАРМа.
2.3. Неформальная постановказадачи
Цель данной работы – реализовать АРМа«Сессия» подсистемы «Деканат». Моя прошлая курсовая работа была посвящена проектированиюданной системы. Сюда входил анализ требований, определение сущностей базы данныхи их связей с другими сущностями.
АРМ «Сессия» ориентирован на задачи секретарядеканата во время сессии:
/>
Рис.1. Задачисекретаря деканата во время сессии
Впоследствии планируется расширять системупутем добавления ролей преподавателя и студента и написания соответствующих клиентов.
2.4. Обзор существующихрешений
Подобные задачи в той или иной степенирешаются каждым ВУЗом. Рассмотрим некоторые разработки, информация о которых доступнав Интернете:
2.4.1. Московский государственный индустриальный университет (МГИУ)
В МГИУ проводились работы по автоматизацииразных подразделений. Однако, работа велась нецентрализованно, поэтому образовалосьмного маленьких проектов, каждый из которых работал на своей базе данных. В процессеработы над мини-проектами уже были найдены оптимальные решения многих проблем, поэтомусо временем образовалась целая глобальная система, получившая название «Проект ВУЗ»[[10]].
К сожалению, на сайте много написано обистории проекта и об его архитектуре, но крайне мало данных о функциональности системыи об ее возможностях.
Одновременно с «Проектом ВУЗ» в МГИУ идетработа над информационно-издательской системой «Диплом» [[11]], автоматизирующей работу Кабинета дипломного проектирования(КДП) МГИУ.
Кабинет дипломного проектирования ВУЗазанимается последней ступенью работы со студентами. Здесь собирается вся информацияоб учебном процессе, успеваемости и личности студентов, окончивших университет,и оформляется в виде официальных документов. Второй проблемой, возникающей при оформлениидокументов, помимо сбора и хранения информации, является печать документов на бланках.Этот процесс также возлагается на сотрудников КДП и связан он с большим количествомрутинной работы по позиционированию и компоновке текста. Целью системы «Диплом»,прежде всего, стало увеличение скорости работы сотрудников и уменьшение затрат наподготовку и оформление документов. Также в данной системе предпринимается попыткаотследить и контролировать случаи повторяющихся тем дипломных работ.
Пакет программ был разработан по принципуклиент-сервер, причем клиентская часть реализована как web-интерфейс с максимальноуменьшенной вычислительной нагрузкой.
Серверная часть включает собственную базуданных, модули обмена информацией с другими информационными системами, модули обработкиинформации, генерации HTML-форм и подготовкик печати. Обмен данных между сервером и клиентом идет через https-протокол с использованием ssl-технологий. База данных работает на СУБДOracle 8. При этом имеется возможность резервногокопирования базы на вспомогательный сервер в автоматическом режиме. Остальные модулиреализованы на Perl.
Печать документов реализована с помощьюиздательской системы LATEX2e. Имеется возможность оформить весь документавтоматически, либо вмешаться в процесс обработки и внести собственные поправки.Во время работы системы генерируется PostScript-файл, хранящий макет документа,что позволяет сохранять документы на будущее.
Система имеет 3 уровня доступа: полный(например, для сотрудников КДП), частичный (например, для деканатов) и только дляпросмотра (например, для руководства ВУЗа). Каждый сотрудник работает с системойкак отдельный пользователь, получая доступ лишь к своей части информации. Например,сотрудники деканата имеют доступ лишь к информации о студентах своего факультетаи имеют право выдавать только академические справки. Учет выданных документов ведетсяавтоматически и всегда есть возможность получить информацию о выданных за тот илииной период документах в виде отчета.
2.4.2. Проект «Naumen University»
Система Naumen University [[12]]— информационно-аналитическая система для организацииуправления учебным процессом в высших и средних специальных учебных заведениях,разработанная компанией Naumen (г. Екатеринбург).Система позиционируется, как универсальная единая информационная среда в рамкахучебного процесса.
В системе заявлена следующая функциональность
· Формализация и прозрачноеуправление организационной структурой вуза;
· Учет и ведение личныхдел студентов, сотрудников, абитуриентов, аспирантов, совместителей;
· Автоматизация работыприемной комиссии;
· Организация движенияконтингента студентов: приказы, выписки из приказов, проведение изменений приказов;
· Формирование и утверждениеучебных и рабочих планов, справочник ГОСов;
· Ведение журналов посещаемостистудентами учебных мероприятий;
· Распределение стипендиипо результатам сессии;
· Ведение базы данныхНИРС;
· Проведение сессии:электронные зачетные книжки, отслеживание академической успеваемости студентов,учет выданных экзаменационных листов, ведение семестровых журналов;
· Управление оплатамиконтрактных студентов;
· Учет совместителей;
· Поддержка процессацелевой подготовки специалистов по договорам со сторонними организациями;
· Оперативное предоставлениеинформации родителям и опекунам студентов;
· Расписание учебныхмероприятий, аттестационных мероприятий в период сессии;
· Управление аудиторнымфондом;
· Расчет нагрузок накафедры;
· Возможность удаленногодоступа к единому банку данных и получения актуальной информации.
В данной системе существует и модуль «Деканат»,обладающий следующей функциональностью:
· Автоматизированноеформирование и печать экзаменационных ведомостей на контрольные мероприятия в соответствиис рабочими планами;
· Ввод результатов контрольныхмероприятий по ведомостям;
· Ведение семестровыхжурналов;
· Формирование, печатьи регистрация экзаменационных/зачётных листов в журнале пересдач, регистрация результатовпересдач;
· Распределение стипендиистудентам по результатам сессии;
· Построение рейтинговфакультета;
· Ведение журнала посещаемости;
· Ведение расписанияучебных мероприятий, контрольных мероприятий для проведения сессии;
· Государственный экзамени дипломное проектирование;
· Печать академическойсправки и приложения к диплому;
· Статистические отчетыи выборки: оценки студента за определённый период, формирование промежуточных иитоговых результатов сессии и зачётной недели, прочие статистические отчеты и выборки.
2.4.3. МГТУ им. Н.Э. Баумана
С 2004 года в МГТУ им. Н.Э.Баумана разрабатываетсяи внедряется единая комплексная система автоматизации работы отделов Университета.[[15]]
До 2004 года автоматизация в МГТУ существоваломножество разрозненных систем, каждая из которых решала только узкие задачи внутрикаждого отдела, причем в большинстве случаев в эти задачи сводились к вводу и поддержаниивсей информации в системе в актуальном состоянии, причем полностью вручную.
Первым важным шагом в процессе автоматизацииУниверситета было принятие общей программы автоматизации. В целом, программа автоматизациипредполагает наличие следующих систем:
«Контингент» — учет информациипо студентам;
«Структура» — учет структурыподразделений Университета;
«Успеваемость» — учет успеваемостистудентов во время семестра и сессии;
«Посещаемость» — учет посещаемостистудентов во время семестра;
«Приемная комиссия» — учет абитуриентови зачисление студентов;
«Безопасность» — единой решениепо организации модели безопасности уровня института;
«ФВО» — учет прохождения обучениястудентов на ФВО;
«Деканат» — автоматизация работыдеканата;
«Бухгалтерия» — автоматизацияработы бухгалтерии, начисление зарплат и стипендий;
«Аналитика» — система для статистическихи иных видов анализов данных других систем;
«Портал» — предоставляет общуюточку доступа ко всем системам, а также средства для общения разработчиков с пользователямии документирования поведения системы;
Все системы, если нет веских причин против,должны предоставлять удовлетворяющий стандартам web-интерфейс и не быть привязанык конкретной платформе (браузер и ОС). Технологической платформой были выбраны web-servicesна протоколе SOAP. Предполагается поддержка SOAP как минимум для решений на базеRuby (SOAP4R), PHP (PHP5 SOAP), Java (Axis и WSIF) и .NET (.NET Web Services).
Система «Контингент» была созданаи введена в эксплуатацию первой. Она решила одну из основных задач автоматизацииУниверситета — в любой момент времени учитывать состояния студентов, структуру Университета,состав групп, движения студентов между группами, ведение личных дел студентов ит.п.
Идеологически система строилась как транзакционнаяобъектная база данных, в которой сущности (студенты, группы, кафедры и т.п.) имеютнекие атрибуты (состояния, принадлежности) и меняют эти атрибуты только по определеннымуказаниям – приказам, максимально отражающим реальные бумажные приказы. Для того,чтобы изменить какую-то информацию о студенте (в том числе создать информацию оновом студенте), должен быть введен в действие соответствующий приказ. ПодразделенияУниверситета готовят внутри системы электронные проекты приказов, далее следуетпроцедура утверждения, в результате которой отдел кадров вводит приказ в действиеи управление делами регистрирует приказ юридически в своем реестре, присваивая емуномер. После введения приказа в действие система автоматически меняет атрибуты узатронутых сущностей.
Таким образом, по каждому студенту накапливаетсяистория приказов, которые когда-либо его касались — как минимум, это приказ о зачислении,переводные приказы (с семестра на семестр) и приказ об окончании обучения, но существуюттакже приказы об академическом отпуске, задолженностях, сроках их сдачи, поселениеи выселении из общежития и т.п.
На данный момент активно ведется разработкадругих систем, которые использует данные, предоставляемые «Контингентом».
2.4.4. Автоматизированная информационная система «Электронный Деканат «ЭД++» РЭАим. Г. В. Плеханова
Автоматизированная информационная система«Электронный Деканат «ЭД++» [[13]] для высшего учебного заведения предназначена для автоматизацииработы деканата. «ЭД++» также построена по технологии клиент-сервер.
В системы реализованы следующие функции(режимы):
· Справочники (справочникспециальностей, справочник групп, справочник образовательных блоков, справочникдисциплин)
· Учебный план (созданиеучебного плана, редактирование учебного плана, дисциплины по выбору)
· Сессии (объявлениеприказа о сессии, проект приказа о сессии, продление сессии)
· Успеваемость (выписываниеведомостей, заполнение ведомости, возврат ведомости)
· Перевод студентов(начать новый учебный год, перевести непереведенных студентов)
· Студенты (матрикулстудента, добавление и удаление студента, изменение информации о студенте, распределениепо группам, учет студентов, обучающихся на платной основе)
· Дипломы (общие положения,создание шаблона диплома, редактирование шаблона, выписка дипломов, редактированиедипломов)
· Отчеты (контингентстудентов, сводная ведомость, итоговая ведомость)
· Новости (пользовательскиеновости, системные новости)
2.4.5. Система «Студент», Санкт-Петербургский государственный университет
Система «Студент» [[14]] позволяет проводить сбор и хранение практически любойинформации о студентах. В составе программного комплекса функционируют следующиеподсистемы:
· Картотека. Учет информациио студентах.
· Приказы.Создание приказов в автоматическом режиме, на основе имеющихся шаблонов.
· Сессия и учебные планы.Включает работу с учебными планами, поддерживает механизм контроля сроков сдачисессии и хранение истории оценок, автоматическое определение академической задолженности,а также ввод, корректировку и хранение всей информации, необходимой работникам деканатав период проведения экзаменационной сессии. Осуществляет печать всех необходимыхвыпускных документов, в том числе массовую.
· Выпуск. Хранение информациио выпускнике, автоматическое составление списка выпускников текущего года, включаявычисление таких данных, как итоговые оценки, средние баллы диплома, определениедипломов с отличием. Также ведется подготовка и печать всех выходных форм в соответствиис существующей нормативной базой СПбГУ.
· Статистика. Служитдля создания статистических отчетов и их анализа. Содержит полный набор типовыхформ, требуемых для отчетности, например: распределение студентов по специальностями курсам на некий момент времени, изменение состояния контингента (с учетом причин)за указанный период времени, распределение студентов по льготным категориям, и многиедругие. Для анализа статистических данных осуществляется переход в список студентовс различными параметрами, уточняющий полученные данные.
2.4.6. Выводы
Все рассмотренные системы решают сходныезадачи с РИВСУУП, однако интеграция некоторых их подсистем в РИВСУУП невозможнавследствие несовместимости платформ и схем данных. Кроме того, во многом РИВСУУПпревосходит любую из этих систем. Также, надо сказать, системы, предоставляемыесторонними разработчиками, уже не являются такими гибкими и адаптируемыми. Например,при изменении структуры учебных планов, при переходе на другие формы контроля, либопри каких-нибудь других изменениях в учебном процессе система никак не сможет наэто отреагировать, потому что разработчиком является третья сторона. РИВСУУП жеразрабатывается коллективом разработчиком непосредственно в МГУ, и все измененияучебного процесса своевременно отражаются.
Также в таких системах практически невозможноучитывать некоторые особенности морского ВУЗа. Поэтому было решено разрабатыватьсобственную подсистему работы с сессиями.
3. Требования к окружению
3.1. Требования к аппаратномуобеспечению
Требуется наличие сервера баз данных,на котором размещалась бы БД, а также должна обеспечиваться связь компьютера клиентас этим сервером.
3.2. Требования к программномуобеспечению
На машине пользователя должен быть установленоADO (драйвер MS SQL Server 2000). На сервере должна существовать БД, соответствующая схемеРИВСУУП.
3.3. Требования к пользователям
Пользователь АРМа должен обладать элементарныминавыками работы с компьютером. Необязательно, но желательно знакомство пользователяс другими АРМами РИВСУУП, т.к. это поможет ему быстрее освоить программу.
Также пользователь должен быть сотрудникомМГУ, быть зарегистрированным пользователем БД и иметь право редактировать данныев этом АРМе. Полномочия пользователей для АРМа «Сессия», как и для всех остальныхАРМов РИВСУУП, определяются с помощью АРМа «Редактор прав пользователей».
Пользователи АРМа «Сессия» делятся надве группы:
Обычные пользователи – сотрудники деканатов.Они имеют право просматривать и редактировать данные только своих деканатов. Полномочияпользователей назначаются в специальном АРМе «Редактирование прав пользователей».
Администраторы – имеют право доступа ковсей информации со всех деканатов. Данная роль введена для упрощения процесса разработкии тестирования программы, конечным пользователям эта роль недоступна.
4. Архитектура системы
На рис. 2 показана схема подсистем и компонентовРИВСУУП и указано, какое место в этой иерархии занимает подсистема «Сессия» в ней:
/>
Рис.2. КомпонентыРИВСУУП
На рис. 3 выделены принципиальные компонентысистемы и их связи.
/>
Рис.3. Компонентысистемы
Назначение компонентов описано в следующейтаблице:
Компонент Описание Core Ядро РИВСУУП [[3]], а также глобальные переменные, используемые в разных модулях Forms Формы АРМа Export Модули, отвечающие за работу экспорта документов в Word и Excel, а также XML-шаблоны ClassesTrees Модули, реализующие бизнес-логику приложения, отвечающие за загрузку, изменение и удаление данных с использованием MObject UI Модули, отвечающие за отображение данных на форме с помощью MGrid Tests Модули, используемые для тестирования клиентаСледует отметить, что все функциональныечасти системы завязаны на ядре РИВСУУП. Бизнес-логика приложения вынесена в самостоятельныемодули, отдельно от пользовательского интерфейса, что позволяет разрабатывать разнообразныетесты на загрузку, сохранение и удаление данных. Тесты на пользовательский интерфейсне пишутся, т.к. критичной надобности в них нет.
5. Спецификация данных
5.1. Сущности системы
5.1.1. Семестр рабочего плана (WorkTerm)
В сущности «Семестр рабочего плана» имеетсмысл рассматривать следующие атрибуты
Название поля Тип Ограничения на допустимые значения Семестр ЧИСЛО [0,11] Рабочий план ЧИСЛО NOT NULL5.1.2. Рабочий план (WorkPlan)
Сущность «Рабочий план», по аналогии среальной жизнью, имеет следующие атрибуты:
Название поля Тип Ограничения на допустимые значения Год ЧИСЛО NOT NULL Факультет ЧИСЛО NOT NULLДанная сущность реализована в БД в видетаблицы
5.1.3. Сессия (Session)
Сущность «Сессия» характеризуется следующимиатрибутами:
Название поля Тип Ограничения на допустимые значения Семестр рабочего плана ЧИСЛО NOT NULL Дата начала DATETIME NOT NULL Продолжительность ЧИСЛО NOT NULL Факультет ЧИСЛО NOT NULL Специальность ЧИСЛО NOT NULLДанная сущность реализована в виде представленияиз уже имеющихся сущностей БД.
5.1.4. Учебное поручение (TeacherPart)
Сущность «Учебное поручение» характеризуетсяследующими атрибутами:
Название поля Тип Ограничения на допустимые значения Группа для занятий ЧИСЛО NULL Дисциплина ЧИСЛО NULL Преподаватель СТРОКА NULL Год ЧИСЛО NOT NULL Семестр ЧИСЛО1 – осенний
2 — весенний
Данная сущность реализована в виде представленияиз уже имеющихся сущностей БД.
5.1.5. Группа (Group)
Сущность «Группа» характеризуется следующимиатрибутами:
Название поля Тип Ограничения на допустимые значения Группа для занятий ЧИСЛО NULL Академическая группа ЧИСЛО NOT NULL Рабочий учебный план ЧИСЛО NOT NULL Название группы СТРОКА NOT NULLДанная сущность реализована в виде представленияиз уже имеющихся сущностей БД. В учебных поручениях хранится именно группа для занятий,которая, в свою очередь, может являться одной академической группой, либо их объединением,либо подгруппой. Сущность «Группа» введена для того, чтобы связать академическиегруппы с учебными поручениями.
5.1.6. Отчетность по дисциплине (DisciplineControl)
Сущность «Отчетность по дисциплине» характеризуетсяследующими атрибутами:
Название поля Тип Ограничения на допустимые значения Семестр рабочего плана ЧИСЛО NOT NULL Дисциплина СТРОКА NOT NULL Академическая группа ЧИСЛО NULL Вид отчетности ЧИСЛО1 – Зачет
2 – Дифференцированный зачет
3 – Экзамен
4 – Экзамен по рейтингу
5 – Гос. Экзамен
6 – Курсовой проект
7 – Курсовая работа
31 – Комплексный экзамен
Данная сущность реализована в виде представленияиз уже имеющихся сущностей БД.
5.1.7. Студент (Student)
Сущность «Студент» характеризуется следующимиатрибутами
Название поля Тип Ограничения на допустимые значения ФИО СТРОКА NOT NULL Академическая группа ЧИСЛО NULLДанная сущность реализована в виде представленияиз уже имеющихся сущностей БД.
5.1.8. Ведомость (ControlRegister)
Сущность «Ведомость» характеризуется следующимиатрибутами
Название поля Тип Ограничения на допустимые значения Отчетность по дисциплине ЧИСЛО NULL Учебное поручение ЧИСЛО NULL Ведомость ЧИСЛО NULL Дата сдачи ДАТА NOT NULLЧто же касается поля «Ведомость», то оновводится для того, чтобы в одной таблице можно было хранить и основные ведомости,и индивидуальные. Суть в том, что основная ведомость хранит ссылки на семестр учебногоплана, учебное поручение и группу. Кроме того, хранится дата сдачи, считающаясяофициальной. На студента, пересдающего отчетность, или сдающего не вовремя, по аналогиис реальной жизнью, заводится индивидуальная ведомость. Она хранит ссылку на основнуюведомость и новую дату сдачи, остальные же поля остаются пустыми, так как уже заполненыв основной ведомости.
5.1.9. Балл (Mark)
Данная сущность представляет собой справочникбаллов. Определены следующие поля:
Название поля Тип Ограничения на допустимые значения Код балла ЧИСЛО NOT NULL Название СТРОКА NOT NULL Короткое название СТРОКА NOT NULLОпределены следующие значения:
Код балла Название Короткое название Неявка н/я 1 Зачтено зачт 2 Не зачтено н/зачт 3 Отлично 5 4 Хорошо 4 5 Удовлетворительно 3 6 Неудовлетворительно 25.1.10. Оценка (Result)
Сущность «Оценка» характеризуется следующимиатрибутами
Название поля Тип Ограничения на допустимые значения Студент ЧИСЛО NOT NULL Ведомость ЧИСЛО NOT NULL Балл ЧИСЛО [0,6]5.2. Схема потоков данных между подсистемами РИВСУУП
/>
Рис.4. Схемапотоков данных между компонентами РИВСУУП
6. Функциональные требования
6.1. Авторизационнаяформа
Отображается при запуске АРМа. Выполняетследующие функции:
· Аутентификация пользователя
· Проверка наличия администраторскихправ
· Определение подразделения,к которому принадлежит данный сотрудник, предоставление прав только в пределах данногоподразделения
Данная форма является стандартной дляАРМов РИВСУУП, она входит в состав ядра.
6.2. Форма выбора факультета
Отображается только для пользователя справами администратора. Позволяет данному пользователю выбрать факультет, в рамкахкоторого он будет работать.
6.3. Главная форма
Координационная форма. Включает в себяменю, в котором можно выбрать деятельность:
· Просмотр сессии;
· Просмотр учебных карточек;
· Выбор факультета (толькодля администратора системы).
6.4. Форма выбора сессии
· Диалог, запрашивающийномер группы, год и семестр;
· Проверка существованиясессии с выбранными параметрами;
· Переход к форме просмотрасписка специальностей.
6.5. Форма выбора учебной карточки
· Диалог, предлагающийвыбрать студента из списка;
· Фильтры, позволяющиепросматривать список студентов, обучавшихся на факультете в выбранный год и в выбраннойгруппе;
· Текстовое поле дляпоиска студента в списке по фамилии;
· Переход к форме учебнойкарточки после выбора студента.
6.6. Форма учебнойкарточки
· Список всех дисциплин,а также отчетностей по ним, из учебного плана специальности, на которой обучаетсявыбранный студент;
· Соответствие учебногоплана рабочим планам (по количеству часов и видам отчетностей);
· Просмотр истории оценокпо данной дисциплине;
· Выставление итоговойоценки.
6.7. Форма просмотрасписка специальностей
· Формирование спискаспециальностей данного факультета, и для каждой специальности – списка курсов игрупп, сдающих выбранную сессию;
· Отображение сроковсессии и количества каждого вида отчетности для каждого потока;
· Предоставление пользователювозможности сформировать сводную ведомость успеваемости выбранной группы, в форматеExcel;
· Предоставление пользователювозможности сформировать все ведомости выбранной группы, в формате Word;
· Выбор группы и переходна форму просмотра отчетностей группы.
6.8. Форма просмотраотчетностей группы
· Список дисциплин,которые данной группе предстоит сдать на этой сессии. Для каждой дисциплины указанвид отчетности;
· Выделение дисциплинпо выбору и факультативов;
· Отображение для каждойдисциплины списка преподавателей, привязанных к ней учебными поручениями. Предусмотренатакже возможность замены преподавателя;
· Выставление дат сдачи.
· Выбор отчетности ипереход на форму зачетно-экзаменационной ведомости
6.9. Форма зачетно-экзаменационнойведомости
· Отображение шапкиведомости, содержащей следующие поля:
– Учебный год;
– Семестр;
– Специальность;
– Группа;
– Число студентов вгруппе;
– Название дисциплина;
– Название кафедры;
– Название отчетности;
– Количество часов;
– ФИО преподавателя.
· Отображение спискагруппы;
· Заполнение следующихполей (для каждого учащегося, по каждой дисциплине):
– Оценка (в соответствиис отчетностью)
– Дата сдачи (если отличаетсяот «официальной», указанной в форме отчетностей)
· Автозаполнение поля«Дата сдачи» (по умолчанию выставляется официальная дата сдачи);
· Сохранение историиоценок;
· Удаление оценок. Еслиистория оценок содержит более одной оценки, то на место удаленной оценки должнавыводиться предшествующая ей;
· Предоставление возможностигенерации печатной формы зачетно-экзаменационной ведомости.
6.10. Автоматическоесоставление печатных документов на основе шаблонов
· Составление ведомостипо выбранной отчетности по дисциплине (в виде документа Word). Ведомость должна содержать заголовокведомости (см. 6.9) и список группы;
· Составление всех ведомостейпо выбранной группе, на выбранной сессии (в виде документа Word). Каждая ведомость должна размещатьсяна отдельной странице;
· Составление своднойведомости выбранной группы (в виде документа Excel). Она должна включать в себя:
– Таблицу, содержащуюоценки всех студентов данной группы по всем отчетностям данной сессии;
– Средние оценки поданной сессии всех студентов данной группы
– Вычисленное количествоотличников, хорошистов, троечников и неуспевающих. Неуспевающим считается человек,не сдавший сессию либо имеющий хотя бы одну оценку «неудовлетворительно», «неявка»или «не допущен»
· Для всех автоматическисозданных документов должно также автоматически создаваться соответствующее им название(например, «Ведомости гр. 01.11 (2006 г 1 сем) »)
6.10.1. Компоненты ядра РИВСУУП,используемые для экспорта документов в Word и Excel
Для автоматического составления печатныхформ была принята та же схема, что и для остальных АРМов РИВСУУП. Составляется XML-шаблон(соответственно, WordML или ExcelML) необходимого документа. В нужные места в шаблоне вставляютсяспециальные теги, которые впоследствии будут заменены данными. Экспорт осуществляетсяс помощью методов классов TMWordMLExporter и TMExcelMLExporter. В объект соответствующего класса загружаетсясам XML-шаблон и блок данных (Dataset), которые надо занести в документ. Послеэтого объект класса экспорта может сгенерировать новый документ, имеющий ту же структуру,что и шаблон и содержащий все данные.
6.11. Требования к интерфейсу
· Интерфейс должен бытьвыполнен в стиле, разработанном ОРПО для АРМов. Для отображения данных в таблицахдолжны быть использованы компоненты ядра РИВСУУП:
/>
Рис.5. АРМыРИВСУУП
· Автозаполнение редактируемыхполей дат.
6.11.1. Визуальные компоненты ядраРИВСУУП
Ядро системы предоставляет следующие компоненты,используемые для загрузки, сохранения и отображения данных.
· TMObject
Представляет из себя абстрактный классобъектов, реализующий механизм доступа к данным через атрибуты. Одним из ключевыхмеханизмов при реализации ИС является механизм поддержки иерархии объектов — прямыхи косвенных отношений между объектами типа родитель-ребенок, а также организациявзаимодействия между ними — механизм рассылки уведомлений. В рамках механизма поддержкииерархии объектов возможно изменение иерархии объектов как в процессе проектирования,так и в процессе выполнения, причем учитываются как прямые связи, так и косвенные.
· MGrid
Класс предоставляет методы для отображенияинформации на экране в табличном виде, в нем также была реализована концепция типизированныхредакторов (редактор текстовой информации, редактор дат, выпадающий список значенийи т.д.). Данный класс оперирует таким понятием, как ячейка, и позволяет строитьгибкий пользовательский интерфейс, комбинируя ячейки различного размера и объединяяих в отдельные области.
7. Проект
7.1. Структура БД
/>
Рис.6. Структурабазы данных
Можно провести аналогию приведенных сущностейбазы данных с ранее описанными сущностями системы (см. 5.1). Соответствие приведено в следующей таблице:
Сущность системы Сущность БД Семестр рабочего плана (WorkTerm) U_WorkTerms Рабочий план (WorkPlan) U_WorkPlans Сессия (Session) VSes_Sessions Учебное поручение (TeacherPart) VSes_TeacherParts Группа (Group) VSes_Groups Отчетность по дисциплине (DisciplineControl) VSes_DisciplineControls Студент (Student) VSes_Persons Ведомость (ControlRegister) D_ControlRegisters Оценка (Result) D_Results, D_ResultsCache Балл (Mark) D_MarksВ основном, поля сущностей БД полностьюсоответствуют атрибутам сущностей системы. Стоит подробнее остановиться на сущности«Оценка», которой соответствует сразу две новых таблицы базы данных. Таблицы имеютсовершенно одинаковую структуру, разница в том, что в D_Resultsхранятся все оценки, а вD_ResultsCache – только актуальные. Это значит, что, если некий студент сдавалодно и то же несколько раз, то в D_Results будет храниться вся история оценок, ав D_ResultsCache – только последняя. В поле Moment хранится дата и время внесения записи (чтобы можно было получитьисторию оценок в порядке их получения). Изначально для хранения оценок была введенатолько одна таблица, но в ней присутствовало поле IsActual, которое указывало, является данная оценкаактуальной или нет. Но схема с двумя таблицами оказалась гораздо удобнее, так какSQL-запросы упростились и стали быстрее выполняться.Целостность данных поддерживается триггерами на добавление и удаление данных в таблицеD_Results: обновляются соответствующие записи в D_ResultsCache.
Также отметим, что сущность «Ведомость»не полностью соответствует таблице D_ControlRegisters, т.к. в последней введено еще одно поля– UGroup. Данное поле изначально не планировалось,но было добавлено исключительно из-за накопившихся в базе данных ошибок. Предполагалось,что академическую группу можно было определить через группу для занятий из соответствующегоучебного поручения. Но так как у поля SGroup не былопоставлено ограничения на непустоту, а также вследствие неправильного ведения пользователямиучебных поручений (АРМ «Учебные поручения»), оказалось, что не всегда в ведомостиможно однозначно определить группу. Через отчетность по дисциплине же однозначноопределить группу также не получалось, потому что там есть ссылка только на рабочийплан, а по одному рабочем плану может обучаться несколько академических групп.
Анализ схемы данных показал некоторыееё недочеты и порой несогласованность, которая и неудивительна в системах такогомасштаба, как РИВСУУП. Например, оказалось, что дисциплины, использующиеся в АРМахподсистемы «Нагрузка и учебные поручения кафедр», не соответствуют дисциплинам,которые пользователи видят в АРМах подсистемы «Учебные планы» (видно на диаграммебазы данных: в представлениях VSes_TeacherParts и VSes_DisciplineControls есть одно и то же строковое поле Discipline). Дело в том, что эти подсистемы разрабатывалисьпрактически независимо друг от друга, и, когда, появился АРМ, использующий данныеиз обеих подсистем, начались сложности. Тем не менее, проблема с дисциплинами былауспешно решена путем реализации необходимых объектов серверной логики.
Реализация АРМа «Сессия» потребовала такженекоторых изменений в АРМе «Курсантский и студенческий отдел кадров» («КСОК») итой части базы данных, с которой он работает. Раньше в «КСОКе» не было привязкистудентов к группам (потому что в этом не было необходимости). Теперь для «КСОКа»введены таблицы, в которых хранится история групп для каждого человека. Были такженайдены и исправлены ошибки хранения данных в АРМе «Редактор рабочих учебных планов».
7.2. Модули и алгоритмы
7.2.1. Модули
Можно рассмотреть соответствие модулейсистемы и компонентов, определенных в главе 4:
/>
Рис.7. Схемавзаимодействия модулей системы
Модуль системы Компонент Описание USesMainForm.pas Forms Описание класса главной формы TfrmMain (см. 6.3) USesSessionsForm.pas Описание класса формы списка специальностей TfrmSessions (см. 6.7) USesGroupControlsForm.pas Описание класса формы работы с формой просмотра отчетностей группы TfrmGroupControls (см. 6.8) USesRegisterForm.pas Описание класса формы работы с зачетно-экзаменационной ведомостью TfrmRegister (см. 6.9) USesSelectFacultyForm.pas Описание класса формы выбора факультета TfrmSelectFaculty (см. 6.2) USesSessionsForm.pas Описание класса формы выбора сессии TfrmSelectSession (см. 6.4) USesSelectStudentForm Описание класса формы выбора студента TfrmSelectStudentForm (см. 6.5) USesStudentCardForm Описание класса формы учебной карточки TfrmStudentCardForm (см. 6.6) USesSpecialityTree.pas ClassesTrees Описание иерархии классов для отображения данных в форме TfrmSessions USesGroupControlsTree.pas Описание иерархии классов для отображения данных в форме TfrmGroupControls USesBaseObjects Описание базовых классов, унаследованных от MObject и используемых в остальных модулях для построения иерархии классов для отображения данных USesRegisterTree Описание иерархии классов для отображения данных в форме TfrmRegister USesStudentCardTree Описание иерархии классов для отображения данных в форме TfrmStudentCard About Core Стандартное для всех АРМов РИВСУУП окно «О программе» Con3 Набор компонентов ядра РИВСУУП, отвечающих за соединение с базой Login2 Авторизационная форма MObject Набор компонентов ядра РИВСУУП для загрузки и хранения данных из БД в специальных объектах. MGrid Набор компонентов ядра РИВСУУП, отвечающих за отображение данных из объектов-наследников TMObject в специальном древесном виде. Входит в ядро РИВСУУП Version Модуль, позволяющий получать версию клиента MTest Ядро системы тестированияТакая структура модулей принята по аналогиис АРМом «КСОК». Программа получается более понятной, а, следовательно, ее легчесопровождать и расширять.
7.2.2. Проект интерфейса
АРМ представляет собой оконное приложениеWin32.
Оформление АРМа «Сессия» соответствуетграфической концепции РИВСУУП, разработанной дизайнером отдела РПО. Введение понятияцветовых схем позволяет соотнести информацию в таблицах к определенному заголовкупо цвету, что позволяет развернуть длинные горизонтальные таблицы вертикально, чтоудобно при анализе информации на экране компьютера. Кроме того, такое представлениеинформации является уже привычным для сотрудников МГУ, по другим АРМам.
Кроме того, интерфейс разрабатывался так,чтобы электронные формы были как можно более похожими на бумажные документы, чтобыпрограмма была интуитивно понятной и легко осваивалась пользователями.
Ниже приведены снимки экранов АРМа.
/>
Рис.8. Окно«О программе»
/>
Рис.9. Формавыбора факультета
/>
Рис. 10. Формавыбора сессии
/>
Рис.11. Формасписка специальностей
/>
Рис. 12. Формасписка отчетностей группы
/>
Рис.13. Формазачетно-экзаменационной ведомости
/>
Рис. 14. Форма выбора учебной карточки
/>
Рис.15. Формаучебной карточки
/>
Рис.16. Сформированнаясводная ведомость успеваемости группы в Excel
/>
Рис. 17. Сформированнаяпечатная ведомость в Word
8. Реализация
8.1. Объем кода
· Объем написанногокода:
SQL (серверная логика, без учета запросов на стороне клиента) 817 строк 30 Кб Delphi 8731 строк 250 Кб Delphi forms 3733 строк 220 Кб XML 2146 строк 82 Кб8.2. Тестирование
Тестирование проводилось по черному ибелому ящику. Классы, используемые в системе, кроме того, тестировались с помощьюавтоматической системы, применяющейся в ОРПО ([4]). Программа была проверена сопровождающими программистами(Отдел сопровождения программного обеспечения МГУ). Также было проведено тестированиепрограммы в реальных условиях: пробная версия была внедрена на Факультете социальногоуправления МГУ на зимней сессии 2006/2007 учебного года.
9. Заключение
В рамках работы были решены следующиезадачи:
· Спроектирована структураАРМа;
· Спроектирован пользовательскийинтерфейс, соответствующий стилю и требованиям РИВСУУП;
· Проведен анализ схемыбазы данных. Введены необходимые сущности, реализованы объекты серверной логики(представления, хранимые процедуры, триггеры, UDF);
· АРМ реализован, выпущенонесколько версий (текущая версия 1.2.1);
· АРМ успешно внедрени используется деканатами МГУ.
Навыки, полученные в ходе работы:
· Программирование дляMicrosoft SQL Server 2000
– Написание хранимыхпроцедур, UDF и триггеров
· Работа в команде ииспользование средств коллективной разработки:
– Система контроля версий– Subversion
– Система управленияпроектами – TBT (внутренняя разработка ОРПО)
– Система автоматического тестирования
· Использование коллективногокода (ядра):
– Низкоуровневая библиотекаработы с БД;
– Аутентификация и авторизацияпользователей;
– Класс объектов, использующийв качестве хранилища данных таблицы в БД;
– Визуальные компоненты(отображение объектов с данными);
– Класс объектов, управляющихвизуальными компонентами;
– Классы, осуществляющиегенерацию печатных форм в формате Word и Excel.
10. Список литературы
[1]. Чистяков, Т. С., Смолин,П. В. Оформление исходных текстов Delphi и стиль программирования среди программистовразличных подразделений МГУ им. адм. Г. И. Невельского, внутренний документ ОРПОЦИТ МГУ, Владивосток: 2004 г.
[2]. Студенческое право,Юридический справочник для студентов, Белгород: 2004 г.
[3]. Ядро информационнойсистемы orpo.msun.ru/kernel.shtml.
[4]. Федоров С. А. Внедрение автоматического тестированияпрограммных продуктов как одного из элементов экстремального программирования
[5]. Грубер, М., Введениев SQL
[6]. Фелёнов, М.Е. БиблияDelphi – СПб.: БХВ-Питербур, 2004 – 880 с.: ил.
[7]. Культин, Н.Б. Delphi6,Программирование на Object Pascal
[8]. Tony Bain, Louis Davidson, Robin Dewsonand Chuck Hawkins, SQL Server 2000 Stored Procedures Handbook
[9]. РИВСУУП – отдел РПОhttp://orpo.msun.ru/rivs.shtml
[10]. Проект «ВУЗ» МГИУ www.chair36.msiu.ru/science/science/articles/3/html/node31.html
[11]. Информационно-издательская система «Диплом»МГИУ www.chair36.msiu.ru/science/science/articles/3/html/node40.html
[12]. «Naumen University» naumen.ru/go/solutions/naumen_university
[13]. АИС «ЭД+», руководство пользователя, ОтделЭкономических Баз Данных РЭА им. Плеханова 2003, 25 с. oebd.rea.ru
[14]. «Студент 2000», руководство пользователя,НИИ ИТ СПбГУ, 2002, 111 с., www.liup.spbu.ru
[15]. Якшин, М.М. Построение системы автоматизацииуниверситета в МГТУ им.Баумана, www.bmstu.ru.