Дипломная работа: Автоматизированное рабочее место
2.4.6. Выводы
Все рассмотренные системы решают сходные задачи с РИВСУУП, однако интеграция некоторых их подсистем в РИВСУУП невозможна вследствие несовместимости платформ и схем данных. Кроме того, во многом РИВСУУП превосходит любую из этих систем. Также, надо сказать, системы, предоставляемые сторонними разработчиками, уже не являются такими гибкими и адаптируемыми. Например, при изменении структуры учебных планов, при переходе на другие формы контроля, либо при каких-нибудь других изменениях в учебном процессе система никак не сможет на это отреагировать, потому что разработчиком является третья сторона. РИВСУУП же разрабатывается коллективом разработчиком непосредственно в МГУ, и все изменения учебного процесса своевременно отражаются.
Также в таких системах практически невозможно учитывать некоторые особенности морского ВУЗа. Поэтому было решено разрабатывать собственную подсистему работы с сессиями.
3. Требования к окружению
3.1. Требования к аппаратному обеспечению
Требуется наличие сервера баз данных, на котором размещалась бы БД, а также должна обеспечиваться связь компьютера клиента с этим сервером.
3.2. Требования к программному обеспечению
На машине пользователя должен быть установлено ADO (драйвер MS SQL Server 2000). На сервере должна существовать БД, соответствующая схеме РИВСУУП.
3.3. Требования к пользователям
Пользователь АРМа должен обладать элементарными навыками работы с компьютером. Необязательно, но желательно знакомство пользователя с другими АРМами РИВСУУП, т.к. это поможет ему быстрее освоить программу.
Также пользователь должен быть сотрудником МГУ, быть зарегистрированным пользователем БД и иметь право редактировать данные в этом АРМе. Полномочия пользователей для АРМа «Сессия», как и для всех остальных АРМов РИВСУУП, определяются с помощью АРМа «Редактор прав пользователей».
Пользователи АРМа «Сессия» делятся на две группы:
Обычные пользователи – сотрудники деканатов. Они имеют право просматривать и редактировать данные только своих деканатов. Полномочия пользователей назначаются в специальном АРМе «Редактирование прав пользователей».
Администраторы – имеют право доступа ко всей информации со всех деканатов. Данная роль введена для упрощения процесса разработки и тестирования программы, конечным пользователям эта роль недоступна.
4. Архитектура системы
На рис. 2 показана схема подсистем и компонентов РИВСУУП и указано, какое место в этой иерархии занимает подсистема «Сессия» в ней:
Рис. 2. Компоненты РИВСУУП
На рис. 3 выделены принципиальные компоненты системы и их связи.
Рис. 3. Компоненты системы
Назначение компонентов описано в следующей таблице:
| Компонент | Описание |
| Core | Ядро РИВСУУП [[3]], а также глобальные переменные, используемые в разных модулях |
| Forms | Формы АРМа |
| Export | Модули, отвечающие за работу экспорта документов в Word и Excel, а также XML-шаблоны |
| ClassesTrees | Модули, реализующие бизнес-логику приложения, отвечающие за загрузку, изменение и удаление данных с использованием MObject |
| UI | Модули, отвечающие за отображение данных на форме с помощью MGrid |
| Tests | Модули, используемые для тестирования клиента |
Следует отметить, что все функциональные части системы завязаны на ядре РИВСУУП. Бизнес-логика приложения вынесена в самостоятельные модули, отдельно от пользовательского интерфейса, что позволяет разрабатывать разнообразные тесты на загрузку, сохранение и удаление данных. Тесты на пользовательский интерфейс не пишутся, т.к. критичной надобности в них нет.
5. Спецификация данных
5.1. Сущности системы
5.1.1. Семестр рабочего плана (WorkTerm)
В сущности «Семестр рабочего плана» имеет смысл рассматривать следующие атрибуты
| Название поля | Тип | Ограничения на допустимые значения |
| Семестр | ЧИСЛО | [0,11] |
| Рабочий план | ЧИСЛО | NOT NULL |
5.1.2. Рабочий план (WorkPlan)
Сущность «Рабочий план», по аналогии с реальной жизнью, имеет следующие атрибуты:
| Название поля | Тип | Ограничения на допустимые значения |
| Год | ЧИСЛО | NOT NULL |
| Факультет | ЧИСЛО | NOT NULL |
Данная сущность реализована в БД в виде таблицы
5.1.3. Сессия (Session)
Сущность «Сессия» характеризуется следующими атрибутами:
| Название поля | Тип | Ограничения на допустимые значения |
| Семестр рабочего плана | ЧИСЛО | NOT NULL |
| Дата начала | DATETIME | NOT NULL |
| Продолжительность | ЧИСЛО | NOT NULL |
| Факультет | ЧИСЛО | NOT NULL |
| Специальность | ЧИСЛО | NOT NULL |
Данная сущность реализована в виде представления из уже имеющихся сущностей БД.
5.1.4. Учебное поручение (TeacherPart)
Сущность «Учебное поручение» характеризуется следующими атрибутами:
| Название поля | Тип | Ограничения на допустимые значения |
| Группа для занятий | ЧИСЛО | NULL |
| Дисциплина | ЧИСЛО | NULL |
| Преподаватель | СТРОКА | NULL |
| Год | ЧИСЛО | NOT NULL |
| Семестр | ЧИСЛО |
1 – осенний 2 - весенний |
Данная сущность реализована в виде представления из уже имеющихся сущностей БД.
5.1.5. Группа (Group)
Сущность «Группа» характеризуется следующими атрибутами:
| Название поля | Тип | Ограничения на допустимые значения |
| Группа для занятий | ЧИСЛО | NULL |
| Академическая группа | ЧИСЛО | NOT NULL |
| Рабочий учебный план | ЧИСЛО | NOT NULL |
| Название группы | СТРОКА | NOT NULL |
Данная сущность реализована в виде представления из уже имеющихся сущностей БД. В учебных поручениях хранится именно группа для занятий, которая, в свою очередь, может являться одной академической группой, либо их объединением, либо подгруппой. Сущность «Группа» введена для того, чтобы связать академические группы с учебными поручениями.
