Автоматизированное рабочее место 2 (стр. 5 из 6)
· Интерфейс должен быть выполнен в стиле, разработанном ОРПО для АРМов. Для отображения данных в таблицах должны быть использованы компоненты ядра РИВСУУП:
Рис. 5. АРМы РИВСУУП
· Автозаполнение редактируемых полей дат.
6.11.1. Визуальные компоненты ядра РИВСУУП
Ядро системы предоставляет следующие компоненты, используемые для загрузки, сохранения и отображения данных.
· TMObject
Представляет из себя абстрактный класс объектов, реализующий механизм доступа к данным через атрибуты. Одним из ключевых механизмов при реализации ИС является механизм поддержки иерархии объектов — прямых и косвенных отношений между объектами типа родитель-ребенок, а также организация взаимодействия между ними - механизм рассылки уведомлений. В рамках механизма поддержки иерархии объектов возможно изменение иерархии объектов как в процессе проектирования, так и в процессе выполнения, причем учитываются как прямые связи, так и косвенные.
· MGrid
Класс предоставляет методы для отображения информации на экране в табличном виде, в нем также была реализована концепция типизированных редакторов (редактор текстовой информации, редактор дат, выпадающий список значений и т.д.). Данный класс оперирует таким понятием, как ячейка, и позволяет строить гибкий пользовательский интерфейс, комбинируя ячейки различного размера и объединяя их в отдельные области.
Рис. 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). Дело в том, что эти подсистемы разрабатывались практически независимо друг от друга, и, когда, появился АРМ, использующий данные из обеих подсистем, начались сложности. Тем не менее, проблема с дисциплинами была успешно решена путем реализации необходимых объектов серверной логики.
Реализация АРМа «Сессия» потребовала также некоторых изменений в АРМе «Курсантский и студенческий отдел кадров» («КСОК») и той части базы данных, с которой он работает. Раньше в «КСОКе» не было привязки студентов к группам (потому что в этом не было необходимости). Теперь для «КСОКа» введены таблицы, в которых хранится история групп для каждого человека. Были также найдены и исправлены ошибки хранения данных в АРМе «Редактор рабочих учебных планов».
Можно рассмотреть соответствие модулей системы и компонентов, определенных в главе 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 | Ядро системы тестирования |
Такая структура модулей принята по аналогии с АРМом «КСОК». Программа получается более понятной, а, следовательно, ее легче сопровождать и расширять.
АРМ представляет собой оконное приложение Win32.
Оформление АРМа «Сессия» соответствует графической концепции РИВСУУП, разработанной дизайнером отдела РПО. Введение понятия цветовых схем позволяет соотнести информацию в таблицах к определенному заголовку по цвету, что позволяет развернуть длинные горизонтальные таблицы вертикально, что удобно при анализе информации на экране компьютера. Кроме того, такое представление информации является уже привычным для сотрудников МГУ, по другим АРМам.
Кроме того, интерфейс разрабатывался так, чтобы электронные формы были как можно более похожими на бумажные документы, чтобы программа была интуитивно понятной и легко осваивалась пользователями.
Ниже приведены снимки экранов АРМа.
Рис. 8. Окно «О программе»
Рис. 9. Форма выбора факультета
Рис. 10. Форма выбора сессии
Рис. 11. Форма списка специальностей
