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

 

1. Компоненты ядра РИВСУУП, используемые для экспорта документов в Word и Excel

Для автоматического составления печатных форм была принята та же схема, что и для остальных АРМов РИВСУУП. Составляется XML-шаблон (соответственно, WordML или ExcelML) необходимого документа. В нужные места в шаблоне вставляются специальные теги, которые впоследствии будут заменены данными. Экспорт осуществляется с помощью методов классов TMWordMLExporter и TMExcelMLExporter. В объект соответствующего класса загружается сам XML-шаблон и блок данных (Dataset), которые надо занести в документ. После этого объект класса экспорта может сгенерировать новый документ, имеющий ту же структуру, что и шаблон и содержащий все данные.

11. Требования к интерфейсу

• Интерфейс должен быть выполнен в стиле, разработанном ОРПО для АРМов. Для отображения данных в таблицах должны быть использованы компоненты ядра РИВСУУП:

 

5. АРМы РИВСУУП

 

• Автозаполнение редактируемых полей дат.

 

1. Визуальные компоненты ядра РИВСУУП

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

• TMObject

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

• MGrid

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

 

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). Дело в том, что эти подсистемы разрабатывались практически независимо друг от друга, и, когда, появился АРМ, использующий данные из обеих подсистем, начались сложности. Тем не менее, проблема с дисциплинами была успешно решена путем реализации необходимых объектов серверной логики.

Реализация АРМа «Сессия» потребовала также некоторых изменений в АРМе «Курсантский и студенческий отдел кадров» («КСОК») и той части базы данных, с которой он работает. Раньше в «КСОКе» не было привязки студентов к группам (потому что в этом не было необходимости). Теперь для «КСОКа» введены таблицы, в которых хранится история групп для каждого человека. Были также найдены и исправлены ошибки хранения данных в АРМе «Редактор рабочих учебных планов».

 

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		Ядро системы тестирования

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

 

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

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

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

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

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

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

1. Объем кода

 

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

 

SQL (серверная логика, без учета запросов на стороне клиента)	817 строк	30 Кб
Delphi	8731 строк	250 Кб
Delphi forms	3733 строк	220 Кб
XML	2146 строк	82 Кб

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.