Проектирование информационной системы для предметной области «Учёт абитуриентов, поступающих в ВУЗ»

 

 

Таблица 3.1 Главный раздел сценария выполнения варианта использования "Поиск по базе данных"
Вариант использования	Поиск
Актеры	Секретарь
Цель	Поиск абитуриентов
Краткое описание	Секретарь ищет данные
Тип	Базовый

 

 

 

 

 

 

 

 

Таблица 3.2 Раздел Типичный ход событий сценария выполнения варианта использования "Поиск по базе данных"
Действия актеров	Отклик системы
1.Секретарь запускает  систему 2. Секретарь входит в систему              4. Секретарь ищет данные в системе     6. Секретарь просматривает данные. 7. Секретарь выходит из системы.	3.Система  даёт доступ БД   Исключение№1  Система сообщает о не существующей записи 5. Система выдаёт запрашиваемые  данные   8. Система возвращается в исходное  состояние.

 

Таблица 3.3 Раздел Исключения сценария выполнения варианта использования "Поиск по базе данных"
Исключение №1.  Отсутствие записи
Действия актера	Отклик системы
2.Изменяет  запрос	1. Система сообщает о не существующей  записи
	3. Система выдаёт запрашиваемые  данные

 

 

 

 

 

 

Таблица 4.1 Главный раздел сценария выполнения варианта использования "Добавление абитуриента в БД"
Вариант использования	Вывод информации
Актеры	Секретарь
Цель	Дополнение или корректировка  информации
Краткое описание	Добавление и изменение  данных
Тип	Базовый

 

Таблица 4.2 Раздел Типичный ход событий сценария выполнения варианта использования " Добавление абитуриента в БД "
Действия актеров	Отклик системы
1.Секретарь запускает  систему 2. Секретарь входит в систему             4. Секретарь вносит изменения  в   данные      5. Секретарь обновляет данные        6. Секретарь сохраняет изменения	3.Система  даёт доступ к интерфейсу     Исключение  №1 Система сообщает о не корректном изменении данных     7.  Система возвращается в исходное  состояние.

 

 

 

 

Таблица 4.3 Раздел Исключения сценария выполнения варианта использования " Добавление абитуриента в БД "
Исключение №1.  Не зачисление
Действия актера	Отклик системы
2. Актёр меняет данные	1. Система сообщает о не корректном  изменении данных 3. Система сохраняет изменения

 

3.2 Диаграмма прецедентов.

Диаграмма прецедентов имеет  следующий вид:

Рис. 1. Диаграмма прецедентов

 

Основным актером является секретарь приемной комиссии ВУЗа, он выполняет три основных действия:

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Логическая модель. Диаграмма классов

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

Граничные классы (boundary classes) – это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами. В пакет «Boundaries» были добавлены следующие классы: класс InputForm(форма ввода данных об абитуриенте) и класс FormaPostupleniy (выбор формы поступления абитуриента).

Классы-сущности (entity classes) отражают основные понятия (абстракции) предметной области и, как правило, содержат хранимую информацию. В данный пакет были добавлен класс Record. Также был создан и добавлен в пакет вспомогательный класс RecordData, предназначенный для того, чтобы облегчить контроль вводимых данных.

Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. В данном проекте данную функцию выполняет класс DataBaseManager, а также TransactionManager

Кандидат на концептуальный класс	Концептуальный  класс
Личные данные	Личные данные (Record)
Форма поступления	Форма поступления (FormaPostupleniy)
Управляющая БД	Управляющая БД (DataBaseManager)
Управление записями	Управление записями (TransactionManager)
Форма ввода	Форма ввода  (InputForm)

 

Рис. 2. Диаграмма классов.

 

На диаграммах классов  отображаются некоторые классы и  пакеты системы.

• выбор формы поступления ( класс – FormPostuplen);
• форма поступления (класс InputForm);
• управляющий БД (класс DataBaseManager) выполняет функции СУБД.
• запись об абитуриенте(класс Record) инкапсулирующего в себе всю необходимую информацию об абитуриенте;
• управляющий записями(класс – TransactionManager)- берущий на себя функции СУБД по управлению транзакциями.

На диаграмму были добавлены  следующие операции:

Create() – создать новую форму о вводе данных абитуриента;

1. OpenForm() – открыть форму для ввода данных абитуриента;
2. InputInfo() – ввести данные об абитуриенте;
3. Saveto() – нажать кнопку сохранить на форме;

5. Физическая модель. Диаграмма компонентов

Этот тип диаграмм предназначен для распределения классов и  объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами  модулей. Cоздана диаграмма компонентов, отображающая распределение классов и объектов по компонентам.

 

Рис. 3. Диаграмма компонентов

система была разложена на два компонента: сервер и клиент. К клиентской части приложения относятся  классы InputForm и FormaPostupleniya и объекты этих классов. К серверной части приложения отнесены все остальные классы и объекты этих классов. Из диаграммы компонентов видно, что разрабатываемая подсистема будет работать по технологии «клиент-сервер».

6. Заключение

В результате выполнения курсовой работы была разработана объектно-ориентированная модель информационной подсистемы для учета подачи документов абитуриентами в ВУЗ. Данная разработка написана с помощью языка UML, с использованием среды разработки – программного продукта Rational Rose 2007.

Были разработаны следующие  диаграммы:

• диаграмма прецедентов;
• диаграмма классов;
• диаграмма компонентов;

Основным действующим  лицом является секретарь приемной комиссии. Он выполняет четыре действия: «просмотреть БД», «добавить абитуриента в БД», «ввод данных абитуриента» «поиск абитуриента».

Наиболее важной и наиболее сложно реализуемой задачей информационной подсистемы является ввод и модификация  информации об абитуриентах, так как  от правильности выполнения этого прецедента зависит успешность оперативного учета  в целом. Информационная подсистема учета абитуриентов университета построена  на технологии «клиент-сервер». Это  позволяет организовать одновременный  доступ нескольких операторов ПК к  базе данных.

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

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

 

Список литературы:

1. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. – М.: Издательство «Лори», 2000.- 581 с., ил.
2. Мартин Ф., Кендалл С. UML Основы / Ф.Мартин, С.Кендалл. - СПб.:Символ-Плюс, 2002. - 192 с.
3. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. – М.: Издательский дом «Вильямс», 2001. – 496 с., ил.
4. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. – М.: ДМК, 2000.- 432 с., ил