Дипломная работа: Информационная система мотивирования и тренировки школьников и студентов в области информатики

Альтернативы:

А1: Открытие таблицы рейтингов.

А1.1: Школьник нажимает на кнопку “Открытие таблицы рейтингов”

А1.2 Система выводит на экран форму, на которой располагается таблица всех пользователей с правами школьника и их рейтингами. Внизу располагается информация о месте Школьника в этой таблице.

А2: Справка.

А2.1: Школьник нажимает на кнопку “Справка”.

А2.2: Система выводит на экран окно со справкой. На окне расположена кнопка “Ок”.

А2.3: Школьник нажимает кнопку “Ок”. Система возвращается на форму, которая была до открытия справки.

А3: Отмена.

А3.1: Школьник нажимает на кнопку “Отмена”.

А3.2: Система возвращается к окну авторизации.

А4: Выход.

А4.1: Школьник нажимает на кнопку “Выход”.

А4.2: Система закрывает программу и возвращает пользователя на рабочий стол операционной системы.

А5: Отмена тестирования.

А5.1: Школьник нажимает на кнопку “Отмена”.

А5.2: Система выводит главную форму приложения, настроенную на права школьника. Изменения в БД не производятся.

Неясные вопросы отсутствуют.

1.4.3 Диаграмма сущностных классов

В UML, так же, как и в объектно-ориентированном программировании, класс (class) - описание множества объектов, обладающих общими атрибутами, операциями, отношениями и поведением. Класс является результатом операции обобщения.

На рисунке 5 изображена разработанная диаграмма сущностных классов. На диаграмме имеются классы: “пользователи”, “тесты”, “вопросы” и “тестирования”. Каждый из них имеет стереотип “entity”. Класс “тесты” связан с классом “вопросы” посредством отношения “ассоциация”. Класс “тестирования” связан с классом “тесты” посредством отношения “ассоциация”. Класс “пользователи” связан с классом “тестирования” посредством ассоциации.

Рисунок 5 - Диаграмма сущностных классов

1.4.4 Диаграмма граничных классов

На рисунке 6 изображена разработанная диаграмма граничных классов. Все классы данной диаграммы имеют стереотип “boundary”. Класс “Окно авторизации” связан с классами “Окно вывода ошибки неверного пароля” и “Главное окно программы”. Класс “Окно регистрации” связан с классом “Главное окно программы”. Класс “Главное окно программы” связан с классами “Окно справки”, “Окно профиля школьника”, “Окно работы преподавателя”, “Окно работы администратора”. Класс “Окно профиля школьника” связан с классами “Окно прохождения тестов” и “Окно таблицы рейтингов”.

Рисунок 6 - Диаграмма граничных классов

1.4.5 Диаграмма классов управления

На рисунке 7 изображена разработанная диаграмма классов управления. Все классы данной диаграммы имеют стереотип “control”. Класс “Менеджер приложения” связан с классом “Менеджер СУБД” посредством отношения “зависимость”.

Рисунок 7 - Диаграмма классов управления

1.4.6 Диаграмма состояний

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

Диаграмма состояний (рисунок А.1) имеет два простых состояния: “Авторизация пользователя” и “Завершение работы приложения”, и два состояния, имеющих вложенные состояния: “Работа с приложением” и “Работа со справочниками”. Состояние “Авторизация пользователя” имеет следующие действия “entry/отобразить форму”, “do/проверить имя и пароль” и “exit/закрыть форму”. Состояние “Завершение работы приложения” имеет действие “do/выйти в операционную систему”. Состояние “Работа с приложением” имеет следующие внутренние состояния: “Работа с электронной ведомостью”, “Работа с картой "Компетенции-Дисциплины"“ и “Работа с результатами расчета”. Состояние “Работа со справочниками” имеет следующие внутренние состояния: “Работа со справочником пользователей” и “Работа со справочником групп студентов”.

1.4.7 Блок-схема основного алгоритма

На рисунке 8 представлена блок-схема основного алгоритма программы с правами школьника.

1.4.8 Разработка логической структуры БД

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

В результате анализа предметной области и, исходя из поставленных задач, для функционирования ИС было выделено четыре сущности:

1) Users - предназначена для хранения данных о пользователях ИС (Атрибуты: id user, fio user, age, rights, username, password, rating);

2) tests - предназначена для хранения данных о кроссвордах (Атрибуты: id test, name, number of questions, difficult, id quest);

3) questions - предназначена для хранения данных о вопросах в кроссворде (Атрибуты: id quest, name, right answer, id test, quest);

4) testing - предназначена для обеспечения целостности данных, хранит данные о конкретном тестировании (Атрибуты: id testing, id user, id test).

Логическая структура БД приведена на рисунке 9.

Рисунок 9 - Логическая структура БД

2. РЕАЛИЗАЦИЯ

2.1 Архитектура и платформа реализации

У разработанной информационной системы локальная архитектура. Это позволяет использовать систему даже на тех ЭВМ, на которых выход в сеть не предусмотрен. Информационная система мотивирования и тренировки школьников и студентов в области информатики реализуется при помощи языка программирования С++ с использованием Фреймворка Qt Creator 3.4.0 (кроссплатформенная свободная IDE для разработки на С,С++ и QML). В системе используется СУБД Sqlite в качестве программного средства, предназначенного для создания структуры новой базы, хранения системной информации, редактирования содержимого и отбора данных в соответствии с заданными критериями, упорядочения, оформления и последующей выдачи данных на устройства вывода или передачи по каналам связи. Данная СУБД была выбрана в качестве средства разработки из-за простоты в проектировании. Программа работает в операционной системе Windows 7 x86/x64, посколькую данная операционная система установлена на большинстве ЭВМ. Также использовались инструментальные средства UML - моделирования - StarUML 2.2.0. В таблице 3 представлены характеристики объекта автоматизации.

Таблица 3 - Характеристики объекта автоматизации

2.2 Физическая структура БД

Физическое проектирование базы данных - процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах. На этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.

В качестве СУБД для разработки базы данных системы использовался Sqlite. Физическая структура БД соответствует разработанной ранее логической структуре.

В таблице 4 приведено соответствие имен сущностей логической структуры и таблиц физической структуры БД.

Таблица 4 - Соответствие сущностей таблицам БД

В таблице 5 приведено соответствие полей и тип связи между ними.

Таблица 5 - связи между полями

Физическая структура реляционной базы данных приведена на рисунке 10.

Рисунок 10 - Физическая структура БД

2.3 Расчет комплекса технических средств

2.3.1 Расчет ресурсов внешней памяти

По формуле (1) был проведен расчёт ресурсов внешней памяти.

, (1)

где V_ВП - общий объем внешней памяти, Гбайт;

V_ОС - объем внешней памяти, требуемый для хранения файлов операционной системы, Гбайт;

V_СУБД - объем внешней памяти, требуемый для хранения файлов СУБД, Гбайт;

V_данных - объем внешней памяти, требуемый для хранения записей базы данных и результатов выполнения функций, Гбайт;

V_{программы} - объем внешней памяти, необходимой для хранения текстов и библиотек приложений, Гбайт.

V_ОС - объем внешней памяти, по паспорту для операционной системы Windows 7 - 2 Гб;

V_СУБД - объем внешней памяти, требуемый для хранения файлов СУБД по паспорту для Sqlite - 0.03 Гб

В таблице 6 показан расчёт максимального объема базы данных.

Таблица 6 - Расчёт объема БД

V данных - объем памяти, требуемый для хранения записей базы данных составляет 0,009 Гб;

V программы - объем внешней памяти, необходимой для хранения текстов и библиотек приложений - 0,1 Гб.

V_ВП = V_ОС (2.0) + V_СУБД (0.03) + V_данных (0.009) + V_{программы} (0.1) = 2.139 Гб

2.3.2 Расчёт требуемых ресурсов оперативной памяти

По формуле (2) был проведен расчёт ресурсов оперативной памяти

, (2)

где V_ОП - общий объем оперативной памяти, Мбайт;

V_ОС - объем оперативной памяти, требуемый для установки операционной системы, Мбайт;

V_СУБД - объем оперативной памяти, требуемый для установки СУБД, Мбайт;

V_данных - объем оперативной памяти, требуемый для хранения записей базы данных и результатов выполнения функций, Мбайт;

V_{программы} - объем оперативной памяти, необходимой для хранения текстов и библиотек приложений, Мбайт.

V_ОС - по паспорту для операционной системы Windows 7 - 16 Гб;

V_СУБД - по паспорту для СУБД Sqlite - 6 Мб:

V _данных - 8,9 Мб (таблица 5);

V _{программы} - 30 Мб.

V_ОП = V_ОС (16384) + V_СУБД (6) + V_данных (8,9) + V_{программы} (30)= 16428,9 Мб.

2.3.3 Требования к техническому и программному обеспечению

Приведем минимальные требования к техническому и программному обеспечению, исходя из расчетов объемов внешней и оперативной памяти, приведенных в п. 2.3.1-2.3.2. Требования к процессору определяются требованиями ОС.

Минимальные требования к рабочей станции:

1) процессор класса Pentium с тактовой частотой 1,6 ГГц и выше;

2) объем оперативной памяти не менее 2 Гб;

3) объем свободного дискового пространства не менее 17 Гб;

4) тип операционной системы - Windows 7 x86/x64;

5) манипулятор типа “мышь”;

6) монитор с разрешением 800x600 и выше.

К системным требованиям и ограничениям относятся:

1) ограничения на программные интерфейсы, в том числе к внешним системам;

2) требования к атрибутам качества;

3) требования к применяемому оборудованию и ПО;

4) требования к документированию;

5) требования к дизайну и удобности интерфейсов;

6) требования к безопасности и надёжности;

7) требования к показателям назначения (производительность, устойчивость к сбоям и т.п.);