ПЗ автоматизації обліку успішності з фізичного виховання

 

В табл. 2.3.5 соответствие объектов содержанию варианту использования «Добавить успеваемость». 

Таблица 2.3.5 – Описание варианта использования «Добавить успеваемость»

Идентификатор		US-5
Название		Добавить  успеваемость
Участники		Преподаватель
Описание		Когда преподаватель  хочет внести данные об успеваемости студента
Предусловие		Пользователь нажимает кнопку «Добавить  успеваемость»
Постусловие		Данные  об успеваемости студента сохраняются  в базу данных
Основной поток событий		Преподаватель нажимает кнопку «Добавить успеваемость» Преподаватель вносит данные в поля при заполнении данных об успеваемости: «Семестр», «Преподаватель», «Норматив», «Оценка», «Дата сдачи» Система проверяет введенные данные, и если в одном из полей отсутствовали данные, то выполняется альтернативный поток событий А. Преподаватель подтверждает изменение данных нажатием кнопки «Подтвердить» Система сохраняет данные об успеваемости. Вариант использования завершается.
Альтернативные потоки	Поток A	Система оповещает преподавателя о том, что поля не должны быть пустыми Вариант использования завершается
	Поток В
Приоритет		Низкий

 

Таблица 2.3.6 – Описание варианта использования «Удалить успеваемость»

 

Идентификатор		US-6
Название		Удалить успеваемость
Участники		Преподаватель
Описание		Когда преподаватель  хочет удалить данные об успеваемости студента
Предусловие		Пользователь нажимает кнопку «Удалить успеваемость»
Постусловие		Данные  об успеваемости студента успешно удалены
Основной поток событий		Преподаватель нажимает кнопку «Удалить успеваемость» Если преподаватель не выбрал данные, которые хочет удалить и нажал кнопку «Удалить успеваемость», то выполняется альтернативный поток А Преподаватель отмечает успеваемость, которую необходимо удалить Преподаватель нажимает кнопку «Удалить успеваемость» Вариант использования завершается.
Альтернативные потоки	Поток A	Система оповещает пользователя, о том, что необходимо выбрать элемент для удаления. Вариант использования завершается.
	Поток В
Приоритет		Низкий

 

В табл. 2.3.7 соответствие объектов содержанию варианту использования «Просмотр успеваемости». 

 

        Таблица 2.3.7 – Описание варианта использования «Просмотр успеваемости»

Идентификатор		US-7
Название		Просмотр  успеваемости
Участники		Преподаватель
Описание		Преподаватель может посмотреть данные об успеваемости студента
Предусловие		Пользователь выбирает студента, о  котором хочет просмотреть информацию, путем нажатия клавишей мышки  на указанного студента
Постусловие		Пользователь  может просмотреть данные об успеваемости
Основной поток событий		Преподаватель просматривает данные об успеваемости студента путем нажатия клавиши компьютерной мыши Компьютер отображает текущее состояние успеваемости студента Вариант использования завершается.
Альтернативные потоки	Поток A
	Поток В
Приоритет		Низкий

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.4 Требования к ПО

2.4.1 Функциональные требования

2.4.1.1  ПО автоматизации учета успеваемости по физическому воспитанию должно выполнять функцию «Добавить студента»:

           - ФИО студента;

           - номер группы;

           - номер телефона;

2.4.1.2 ПО должно выполнять функцию «Редактировать студента».

2.4.1.3 ПО должно выполнять функцию «Удалить студента».

2.4.1.4 ПО должно выполнять функцию «Добавить успеваемость».

2.4.1.5   ПО должно хранить данные об успеваемости студента:

         - Номер  семестра;

         - Преподаватель,  принимающий норматив;

         - Вид норматива;

         - Оценка;

         - Дата сдачи;

2.4.1.6 ПО должно предусматривать функцию «Удалить успеваемость».

2.4.1.7 ПО должно показывать данные об успеваемости студента.

2.4.2 Нефункциональные требования

2.4.2.1  Объем оперативной памяти должен быть минимум 512Мб;

2.4.2.2 ПО «Физическое воспитание учебного заведения» должно иметь двухуровневую архитектуру;

2.4.2.3 ПО должно корректно обрабатывать ошибки (исключения) и показывать форму, сообщающую о непредвиденной ситуации в случае возникновения необработанной ошибки;

2.4.2.4 ПО «Физическое воспитание учебного заведения» должно хранить информацию о студентах и успеваемости в базе данных MYSQL Server;

2.4.2.5 В качестве инструментальных средств разработки должен использоваться пакет разработчика фирмы Sun Microsystems Inc. J2SE SDK версии 1.2 и выше (платформа Java 2).

2.4.2.6  Время отклика ПО должно составлять не более 1сек.

2.4.2.7  ПО должна работать с ОС Windows.

2.4.2.8 ПО должно корректно взаимодействовать с любыми антивирусами, установленными на компьютере.

2.4.2.9 ПО должно предоставлять интуитивно понятный пользовательский интерфейс;

3 Архитектурное и детальное проектирование ПО

1. Архитектурное проектирование клиентской части ПО

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

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

       Следовательно, разрабатываемое ПО состоит из двух основных частей.

Первая – это клиентская часть  для доступа и манипуляции  данными со стороны рабочего места  пользователя. Клиентская часть будет  общаться с СУБД MySQL посредством  выдачи запросов.

Вторая – это серверная часть, включающая в себя собственно модель БД, отражающая предметную область, и  реализованная таблицах и других объектах БД для хранения информации. БД находится под управлением  СУБД MySQL.

 

Приложение  реализовано на основе объектно-ориентированного подхода к программированию. На основе диаграммы вариантов использования (рис.2.3.1) были выделены концептуальные классы, представленые на рисунке 3.1.1.

Рисунок 3.1- Концептуальные классы ПО

3.2 Архитектурное проектирование серверной части ПО

3.2.1 Логическая модель даннях

3.2.1.1 Выделение сущностей и атрибутов предметной области

 

 Выделение сущностей БД

 

 Для предметной «Физическое воспитание учебного заведения» были выделены сущности, представленные на рисунке 3.1

 

 

Рисунок 3.2 – Сущности базы данных.

 

Описание сущностей:

 

Department(кафедра) – содержит код кафедры, название кафедры и номер факультета.

Faculty(факультет) – содержит название факультета.

Group(группа) – сущность, содержащая номер кафедры и название группы.

Lecturer(преподаватель) – сущность, содержащая номер кафедры, ФИО преподавателя.

Normative(нормативы)– содержит название норматива.

Result(оценка) – содержит номер семестра, номер преподавателя, номер норматива, номер студента, оценку и дату сдачи.

Semester(семестр)– содержит название(номер) семестра.

Student(студент) – сущность, содержащая ФИО студента, номер группы, номер телефона.

Определение атрибутов  сущностей

 

Рассмотрев предметную область  и проанализировав ее, выделяем следующие  сущности:

1. Faculty

• id_faculty (PRIMARY KEY)

• name_faculty

2. Department

• id_department (PRIMARY KEY)
• code_department
• name_department
• id_faculty

3. Group

• id_group (PRIMARY KEY)
• id_department
• name_group

4. Normative

• id_normative (PRIMARY KEY)
• name_normative

5. Semestr

• id_semestr (PRIMARY KEY)
• name_semestr

6. Student

• id_student (PRIMARY KEY)
• surname_student
• firstname_student
• middlename_student
• id_group
• phone_student

7. Lecturer

• id_lecturer (PRIMARY KEY)
• id_department
• surname_lecturer
• firstname_lecturer
• middlename_lecturer

8. Result

• id_result (PRIMARY KEY)
• id_semestr
• id_lecturer
• id_normative
• id_student
• evaluation
• delivery_date

3.2.2  Выделение  связей между сущностями

Связь 1:1

В БД нет связи 1:1 между сущностями, т.е. нет таких сущностей, для которых одна запись одной таблицы ассоциировалась бы только с одной записью второй таблицы.

Связь 1:m

Связь 1:m существует между следующими сущностями:

Рисунок 3.3 – ER-диаграмма связи Преподаватель - Успеваемость

 

Рисунок 3.4  – ER-диаграмма связи Студент – Нормативы

 

Рисунок 3.3 – ER-диаграмма связи Норматив – Оценки

 

Связь m:n

В БД нет связи m:n (многие ко многим).

3.2.3  Построение логической схемы БД

На основании  требований и выделенных атрибутов  в предыдущем разделе, получаем логическую диаграмму БД

 

Рисунок 3.4 – Логическая ER-диаграмма БД

3.3  Детальное проектирование ПО

3.3.1 Детальное проектирование клиентской части ПО

 

Разрабатываемое распределенное программное приложение должно быть реализовано с применением двухуровневой  архитектуры  клиент-сервер.

Функциональная схема ПО приведена на рисунке 3.4.

  Рисунок.  3.5 – Архитектура приложения ПО автоматизации учета успеваемости по физическому воспитанию

 

Рисунок 3.6 – Cтруктура классов проекта

 

В пакете viev разработаны следующие классы форм приложения:

JFrameMain.java – главная форма приложения. Позволяет просматривать данные о студентах, редактировать информацию о студентах и нормативах, доступ к следующим формам приложения.

JFrameLogin.java – форма для авторизации пользователей.

JDialogStudent. java – форма добавления студента, позволяет обновлять таблицы Студенты в БД, добавлять студентов в БД, редактировать и удалять информацию о студентах.

JDialogResult. java – форма добавления новой успеваемости, позволяет заносить данные о нормативах в БД.