Описание предметной области
Обзор существующих решений
МГТУ им. Н.Э. Баумана
Система «Студент», Санкт-Петербургский государственный университет
Рабочий план (WorkPlan)
Отчетность по дисциплине (DisciplineControl)
Балл (Mark)
Форма учебной карточки
Визуальные компоненты ядра РИВСУУП
Модули и алгоритмы
Проект интерфейса
Навигация
Визуальные компоненты ядра РИВСУУП
Автоматизированное рабочее место
48147
знаков
16
таблиц
17
изображений
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). Дело в том, что эти подсистемы разрабатывались практически независимо друг от друга, и, когда, появился АРМ, использующий данные из обеих подсистем, начались сложности. Тем не менее, проблема с дисциплинами была успешно решена путем реализации необходимых объектов серверной логики.
Реализация АРМа «Сессия» потребовала также некоторых изменений в АРМе «Курсантский и студенческий отдел кадров» («КСОК») и той части базы данных, с которой он работает. Раньше в «КСОКе» не было привязки студентов к группам (потому что в этом не было необходимости). Теперь для «КСОКа» введены таблицы, в которых хранится история групп для каждого человека. Были также найдены и исправлены ошибки хранения данных в АРМе «Редактор рабочих учебных планов».
Похожие работы
... продукта, затрат на разработку, для определения конкурентоспособности программного продукта. 5.1 Описание программного продукта Наименование программного продукта: «Автоматизированное рабочее место инженера станции технического обслуживания ИПОсит». Основные характеристики. Система предназначена для повышения эффективности работы сотрудников с запчастями, поставляемые дилерами на СТО, ...
... , является ОС ДТ-МАКС (DT-MAX) версии 6.0, которая и применены в данном комплексе. основные решения по реализации компонентов системы Общие положения Разрабатываемое автоматизированное рабочее место оператора автоматических кабин и информационной системы предназначено для работы на городских отделения электросвязи (ГОЭС) в составе автоматизированной системы управления АПП ГОЭС. АРМ АПП ...
... цена 916152 3. Экономическая эффективность разработки Основная задача, поставленная перед разработчиком – это создание программного обеспечения (ПО) для автоматизированного рабочего места регистрации и документирования комплекса средств автоматизации. Разработка не имела ранее подобных аналогов и является специализированным ПО, которое обеспечивает следующие функции: получение и ...
... к/с 3044410500000880000. 1.3. Перечень документов, на основании которых создается АС: Документы, на основании которых создается система: 1 Договор от 15.11.2003 «О создании автоматизированного рабочего места специалиста по кадрам ООО «Техресурс» 2 Материалы обследования ООО «Техресурс»; 3 Разработка концепции автоматизированной системы. 1.4. Плановые сроки начала и окончания работы ...
0 комментариев