Дипломная работа: Автоматизированное рабочее место 2

М инистерство образования РФ

Дальневосточный государственный университет

Институт математики и компьютерных наук

Кафедра информатики

Автоматизированное рабочее место

«СЕССИЯ»

Дипломная работа

студентки гр. 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.

Печать документов реализована с помощью издательской системы L^A TEX2_e . Имеется возможность оформить весь документ автоматически, либо вмешаться в процесс обработки и внести собственные поправки. Во время работы системы генерируется 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. Компоненты системы

Назначение компонентов описано в следующей таблице:

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

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. Схема потоков данных между подсистемами РИВСУУП

Рис. 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). Соответствие приведено в следующей таблице:

В основном, поля сущностей БД полностью соответствуют атрибутам сущностей системы. Стоит подробнее остановиться на сущности «Оценка», которой соответствует сразу две новых таблицы базы данных. Таблицы имеют совершенно одинаковую структуру, разница в том, что в 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. Схема взаимодействия модулей системы

Такая структура модулей принята по аналогии с АРМом «КСОК». Программа получается более понятной, а, следовательно, ее легче сопровождать и расширять.

7.2.2. Проект интерфейса

АРМ представляет собой оконное приложение Win32.

Оформление АРМа «Сессия» соответствует графической концепции РИВСУУП, разработанной дизайнером отдела РПО. Введение понятия цветовых схем позволяет соотнести информацию в таблицах к определенному заголовку по цвету, что позволяет развернуть длинные горизонтальные таблицы вертикально, что удобно при анализе информации на экране компьютера. Кроме того, такое представление информации является уже привычным для сотрудников МГУ, по другим АРМам.

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

Ниже приведены снимки экранов АРМа.

Рис. 8. Окно «О программе»

Рис. 9. Форма выбора факультета

Рис. 10. Форма выбора сессии

Рис. 11. Форма списка специальностей

Рис. 12. Форма списка отчетностей группы

Рис. 13. Форма зачетно-экзаменационной ведомости

Рис. 14. Форма выбора учебной карточки

Рис. 15. Форма учебной карточки

Рис. 16. Сформированная сводная ведомость успеваемости группы в Excel

Рис. 17. Сформированная печатная ведомость в Word

8. Реализация

8.1. Объем кода

· Объем написанного кода:

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]. Ядро информационной системы http://orpo.msun.ru/kernel.shtml.

[4]. Федоров С. А. Внедрение автоматического тестирования программных продуктов как одного из элементов экстремального программирования

[5]. Грубер, М., Введение в SQL

[6]. Фелёнов, М.Е. Библия Delphi – СПб.: БХВ-Питербур, 2004 – 880 с.:ил.

[7]. Культин, Н.Б. Delphi6, Программирование на Object Pascal

[8]. Tony Bain, Louis Davidson, Robin Dewson and Chuck Hawkins, SQL Server 2000 Stored Procedures Handbook

[9]. РИВСУУП – отдел РПО http://orpo.msun.ru/rivs.shtml

[10]. Проект «ВУЗ» МГИУ http://www.chair36.msiu.ru/science/science/articles/3/html/node31.html

[11]. Информационно-издательская система «Диплом» МГИУ http://www.chair36.msiu.ru/science/science/articles/3/html/node40.html

[12]. «Naumen University» http://naumen.ru/go/solutions/naumen_university

[13]. АИС «ЭД+», руководство пользователя, Отдел Экономических Баз Данных РЭА им. Плеханова 2003, 25 с. http://oebd.rea.ru

[14]. «Студент 2000», руководство пользователя, НИИ ИТ СПбГУ, 2002, 111 с., www.liup.spbu.ru

[15]. Якшин, М.М. Построение системы автоматизации университета в МГТУ им.Баумана, www.bmstu.ru.