перейти к полному списку дипломных проектов
Ссылка на скачивания файла в формате .doc находится в конце странички
Раньше в «КСОКе» не было привязки студентов к группам (потому что в этом не было необходимости)
После этого объект класса экспорта может сгенерировать новый документ, имеющий ту же структуру, что и шаблон и содержащий все данные.
Требования к интерфейсу
Интерфейс должен быть выполнен в стиле, разработанном ОРПО для АРМов. Для отображения данных в таблицах должны быть использованы компоненты ядра РИВСУУП:
АРМы РИВСУУП
Автозаполнение редактируемых полей дат.
Визуальные компоненты ядра РИВСУУП
Ядро системы предоставляет следующие компоненты, используемые для загрузки, сохранения и отображения данных.
TMObject
Представляет из себя абстрактный класс объектов, реализующий механизм доступа к данным через атрибуты. Одним из ключевых механизмов при реализации ИС является механизм поддержки иерархии объектов — прямых и косвенных отношений между объектами типа родитель-ребенок, а также организация взаимодействия между ними - механизм рассылки уведомлений. В рамках механизма поддержки иерархии объектов возможно изменение иерархии объектов как в процессе проектирования, так и в процессе выполнения, причем учитываются как прямые связи, так и косвенные.
MGrid
Класс предоставляет методы для отображения информации на экране в табличном виде, в нем также была реализована концепция типизированных редакторов (редактор текстовой информации, редактор дат, выпадающий список значений и т.д.). Данный класс оперирует таким понятием, как ячейка, и позволяет строить гибкий пользовательский интерфейс, комбинируя ячейки различного размера и объединяя их в отдельные области.
Проект
Структура БД
Структура базы данных
Можно провести аналогию приведенных сущностей базы данных с ранее описанными сущностями системы (см. 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). Дело в том, что эти подсистемы разрабатывались практически независимо друг от друга, и, когда, появился АРМ, использующий данные из обеих подсистем, начались сложности. Тем не менее, проблема с дисциплинами была успешно решена путем реализации необходимых объектов серверной логики.
Реализация АРМа «Сессия» потребовала также некоторых изменений в АРМе «Курсантский и студенческий отдел кадров» («КСОК») и той части базы данных, с которой он работает. Раньше в «КСОКе» не было привязки студентов к группам (потому что в этом не было необходимости).
скачать бесплатно Автоматизированное рабочее место
Содержание дипломной работы
256
Коноваловой Д
256
Коноваловой Д
Второй проблемой, возникающей при оформлении документов, помимо сбора и хранения информации, является печать документов на бланках
Первым важным шагом в процессе автоматизации Университета было принятие общей программы автоматизации
Выводы
Все рассмотренные системы решают сходные задачи с РИВСУУП, однако интеграция некоторых их подсистем в РИВСУУП невозможна вследствие несовместимости платформ и схем данных
Студент (Student)
Сущность «Студент» характеризуется следующими атрибутами
Данная сущность реализована в виде представления из уже имеющихся сущностей БД
9) и список группы;
Составление всех ведомостей по выбранной группе, на выбранной сессии (в виде документа Word)
Раньше в «КСОКе» не было привязки студентов к группам (потому что в этом не было необходимости)
Студенческое право, Юридический справочник для студентов, Белгород: 2004 г
С учетом имеющихся знаний относительно построения баз данных с помощью SQL технологии и архитектуры «клиент-сервер» было принято решение написать новую программу с учетом приведенных требований
