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

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

Рубрика Педагогика
Вид дипломная работа
Язык русский
Дата добавления 08.10.2018
Размер файла 3,3 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к дипломному проекту на тему:

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

РЕФЕРАТ

Дипломный проект.

Пояснительная записка: 137 с., 21 рис., 12 табл., 26 источников, 4 приложения.

Межпредметные связи, Взаимозависимость дисциплин, матрица связей, ИНФОРМАЦИОННАЯ СИСТЕМА.

Объектом проектирования является информационная система подготовки студентов к занятиям в семестре.

Предметная область - межпредметные связи.

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

- разработать математический аппарат расчета коэффициентов взаимозависимости дисциплин;

- собрать данные для математической модели;

- произвести расчет коэффициентов взаимозависимости дисциплин;

- разработать тесты и рекомендации по предметам для студентов.

- В результате мы

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

ВВЕДЕНИЕ

студент учебный дисциплина

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

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

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

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

Итогом работы будет являться ИС, предназначенный для деканов, преподавателей и студентов, который призван решать задачу повышения качества образования.

1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Описание и анализ предметной области

Перед высшим образованием на текущий момент стоят несколько важных задач, таких как содействие профессиональному становлению и развитию творчески мыслящих личностей [1-3].

Поиски эффективных путей повышения воспитательного уровня процесса обучения в школе все больше привлекают внимание педагогов, ученых и практиков к проблеме межпредметных связей. В исследованиях известных ученых-педагогов (И.Д. Зверева, В.М. Коротова, М.Н. Скаткина и др.) межпредметные связи выступают как условие единства обучения и воспитания, средство комплексного подхода к предметной системе обучения[4-6]. Многие авторы определяют межпредметные связи как «дидактическое условие успешного обучения» (В. Н. Максимова и др.) [7] . Другие как педагогическую категорию (В. Н. Федорова, П. Г. Кулагин). Однако следует заметить, что в самом определении уже заложено понятия системности, т.к. его функции составляют динамичную систему управления развитием учащихся, через методически обоснованное интегративное использование учебных дисциплин, позволяющее охватить все стороны изучаемого предмета, его связи с другими предметами.

Зверев также отмечает тот факт, что многообразие межпредметных связей в процессе обучения показывает, что сущность данного понятия не может быть определена однозначно [5]. Различные исследователи по-разному трактуют термин «межпредметные связи», порой даже в нескольких значениях сразу. Причина же заключается в их многофункциональном характере. В научно-педагогической литературе можно встретить около 40 определений данного понятия, что приводит к искажению понимая термина.

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

Связи бывают разные по форме:

- по составу;

- по направлению;

- по способу взаимодействия.

По составу выделяют несколько видов:

- содержательные;

- операционные;

- методические;

- организационные.

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

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

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

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

Примем следующие обозначения:

Пусть в группе имеется K студентов. k = 1..K;

У группы есть некоторое количество дисциплин I, i = 1..I

Имеются результаты сессии А = [aki], где

k - номер студента;

i - номер дисциплины.

Дисциплины образуют собой матрицу взаимосвязей:

B = [bij] , i = 1..I, j = 1..I, bij >0

и матрицу возможности зависимости:

C = [cij] , i = 1..I, j = 1..I, ,

На текущий семестр матрица прогнозируемых оценок:

Dki, i = 1..I, k = 1..K

Прогнозируемая оценка вычисляется по формуле 1.1:

(1.1)

где i - номер дисциплины, для которой рассчитывается оценка;

j - номера дисциплин, которые были в предыдущих семестрах;

k - номер студента.

Таким образом, мы рассчитали прогнозируемые оценки, с первоначальными

Далее рассчитывается матрица невязок реальных оценок и прогнозируемых:

(1.2)

и сумма квадратов невязок H:

(1.3)

Таким образом, математическая задача сводится к задаче поиска минимума функции многих переменных суммы квадратов невязок, где изменяемыми параметрами является матрица взаимосвязей B.

Расчет производится в несколько итераций, начиная со второго семестра и заканчивая последним.

Основной проблемой в математической модели является большое количество переменных. Если исходить из расчета, что у учебной группы 9 учебных семестров, и в каждом семестре 10 учебных предметов, то на последнем шаге итерации у нас будет около 800 изменяемых параметров функции. Даже с учетом того, что часть переменных исключается из поиска в матрице возможной зависимости, оставшееся число параметров будет крайне велико. Даже если у нас останется 100 параметров, при шаге параметра 0.1 в ходе простого перебора всех параметров будет произведено 10100 расчетов. Также это делает сложным применение точных математических методов. Поэтому для расчетов был выбран метод случайного поиска (метод Монте-Карло), который предполагает равномерного случайного выбора множества точек из пространства поиска и отталкиваясь от них искать методом спуска локальные минимумы; затем мы выбираем из найденных локальных минимумов тот, что наиболее соответствует условию задачи.

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

2.1

1.2 Обзор аналогов

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

«Let's test»

«Let's test» - это Интернет-сервис, который позволяет в кратчайшие сроки развернуть полноценную платформу для проведения тестирования знаний. Для того, чтобы использовать систему онлайн тестирования не требуется скачивать и устанавливать какие-либо программы, необходим только браузер и доступ в интернет [11].

Система тестирования «Let's test» позволяет проводить онлайн тестирования знаний через интернет. Она является не просто конструктором тестов, а обладает широким набором функциональных возможностей, благодаря которым можно построить целую инфраструктуру для вашей организации (рисунок 1.1):

- управление системой. Вы можете зарегистрировать свою организацию и получить изолированную систему тестирования с полным контролем над ней;

- тестовые задания. Есть возможность создавать тесты онлайн и добавлять их в базу тестовых заданий своей организации;

- результаты и отчетность. В системе хранятся результаты всех тестирований, а также ответы пользователей на каждый из вопросов;

- пользователи. Вы имеете полный контроль над пользователями, которые состоят в вашей организации;

- тестирование. Проводите тестирования знаний студентов или учеников, оценивайте уровень профессиональных навыков сотрудников или кандидатов на должность;

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

а) встраивание тестирований на свой сайт;

б) анкеты для сбора данных о тестируемых;

в) отправка уведомлений на почту;

г) возможность добавить логотип и фирменный стиль вашей организации;

д) одновременная работа в системе неограниченного количества пользователей.

Рисунок 1.1 - Структура системы «Let's Test»

«OpenTest»

Система тестирования «OpenTest» - это простой и удобный в использовании компьютерный инструмент тестирования и проверки знаний. «OpenTest» позволяет разрабатывать тесты, проводить как промежуточное, так и итоговое тестирование, осуществлять подготовку к экзаменам и анализировать результаты [12].

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

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

Рисунок 1.2 - Интерфейс системы «OpenTest»

- Специальные функции. Используйте продвинутые возможности настройки собственного центра тестирования:

а) Кастомизация под бренд. Создавайте фирменный дизайн страницы теста для своей компании;

б) Тестирование на бумаге. Создавайте тесты в PDF для печати и тестирования без интернета и компьютера;

в) Шкалы баллов. Создавайте собственные шкалы оценивания с баллам или процентами;

г) Шаблоны сертификатов. Создавайте бланки собственных сертификатов и наград для участников с лучшими результатами;

д) Анкета тестирования. Настраивайте индивидуальную анкету для сбора данных с участников тестирования;

е) Коллективное создание тестов. Создавайте и корректируйте тест командой авторов и экспертов.

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

- Оценка заданий. Собирайте отзывы к тестовым заданиям для фокус-тестирования и проверки качества теста;

- Выборки заданий. Создавайте собственные выборки заданий из базы вопросов, группируйте и перемешивайте их;

- Защищенное тестирование. Устанавливайте пароли и лимиты на тест или предварительно регистрируйте участников.

Сравнение систем

2.1.1 В таблице 1.1 представлено сравнение разработанной мной системы с аналогами.

Таблица 1.1 - Сравнение систем

Критерии

ИНПОДСТУД

«LetsTest»

«OpenTest»

Разбиение тестов по категориям

Да, по предметам

Да

Нет

Случайный порядок вопросов и ответов

Да

Да

Да

Анализ результатов тестирования (отличительная особенность)

Да

Статистика распределения времени по вопросам и возвратов к вопросу

Да

Экспорт результатов в разные форматы

Да

Отзывы к вопросам

Система разграничения доступа к тестам

Да

Да

Да

Просмотр результатов тестирований, а также детальной информации по каждому сеансу.

Да

Да

Да

Выдача различных описаний в зависимости от результата

Да

Нет

Нет

Вопросы разных типов

Нет

Да

Да

Цена

15000 единовременно

Бесплатная /

390р. в мес. /

990р. в мес. /

Платная, цена скрыта.

Оплата в виде месячной подписки

Из таблицы 1.1 видно, что в плане тестирования как разрабатываемая ИС, так и конкурирующие системы в плане проведения тестирования имеют свои достоинства и недостатки

2.2

1.3 Обоснование цели создания ИС

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

Для наглядного представления общих и частных целей создания информационной системы составим дерево целей, которое представляет собой структурированный иерархический перечень целей, в котором цели низкого уровня подчинены и служат для достижения целей более высокого уровня (рисунок 1.3), а также измеряемые параметры достижения цели (таблица 1.2), дерево задач (рисунок 1.4)

Рисунок 1.3 - Дерево целей ИС «ИНПОДСТУД»

Рисунок 1.4 - Дерево задач ИС «ИНПОДСТУД»

Таблица 1.2 - Измеряемые параметры для дерева целей

ЦЕЛЬ

ПАРАМЕТРЫ

Возможность применения решения на множестве групп

количество групп, воспользовавшихся данным комплексом

Повышение итоговых результатов обучения студента

% студентов из групп с точным прогнозом результатов, которым были даны рекомендации по улучшению освоения учебного предмета и их итоговая оценка по этому предмету оказалась выше, чем прогнозировалась сначала

Повышение эффективности алгоритма выбора лучшей альтернативы

% групп, в случае которых был дан точный прогноз по результату обучения

Повышение качества выявления междисциплинарных связей

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

2.3

1.3 Проектирование

При проектировании использовалась технология UML. UML - это унифицированный язык моделирования для описания, визуализации и документирования объектно-ориентированных систем и бизнес-процессов в ходе разработки программных приложений [13]. Он был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML позволяет разработчикам ПО достигнуть соглашения в графических обозначениях для представления общих понятий.

2.4

1.4 Диаграмма вариантов использования

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

Диаграмма вариантов использования разрабатываемой системы представлена на рисунке 1.5. Система содержит 6 актантов: «Пользователь», «Преподаватель», «Студент», «Декан», «Секретарь деканата» и «Администратор».

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

«Преподаватель» - Пользователь, который может вводить и редактировать информацию, а также просматривать отчеты.

«Студент» - Пользователь, который может формировать отчеты и проходить тестирование.

«Декан» - Пользователь, который может формировать отчеты.

«Секретарь деканата» - Пользователь, который может вводить и редактировать информацию.

«Администратор» - обладает правами ведения справочника пользователей.

2.5

1.5 Сценарии вариантов использования

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

Сценарий 1

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

Краткое описание: Данный вариант использования позволяет Преподавателю составить тест для лучшего усвоения своего предмета.

Актор: Преподаватель

Предусловия: Компьютер включен, система загружена, выполнен вариант использования «Вход в систему» с правами Преподавателя. На экране загружено главное окно программы с меню: «Мои предметы», «Выход» и списком своих предметов, напротив позиций которого есть кнопка «Тесты».

Основной поток событий

1. Преподаватель нажимает кнопку «Тесты по предмету», соответствующей одному из предметов.

А1: Выход

2. Система выводит страницу «Тесты по предмету», к заголовку добавлено название предмета через пробел. На экран выводится список тестов по предмету, список ссылок на результаты тестирования, заполненные актуальными данными из БД, кнопка «Добавить тест».

А2: Закрытие страницы

А3: Просмотр результатов тестирования

А4: Редактирование теста

3. Преподаватель нажимает кнопку «Добавить тест».

4. Система выводит страницу «Добавление теста по предмету», содержащей форму добавления нового теста.

5. Преподаватель заполняет форму «Добавление теста по предмету» и нажимает кнопку «Отправить».

6. Система сохраняет введенные данные, закрывает страницу «Добавление теста по предмету» и выводит на экран страницу «Тесты по предмету». Вариант использования завершается успешно.

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

A1: Выход

А1.1 Преподаватель выбирает пункт меню «Выход»

А1.2 Система сбрасывает данные авторизации пользователя и выводит страницу ввода логина и пароля. Вариант использования завершается

А2: Закрытие страницы

А2.1 Преподаватель нажимает кнопку «Закрыть».

А2.2 Система осуществляет выход в окно операционной системы, закрывая приложение. Вариант использования завершается.

А3: Просмотр результатов тестирования

А3.1 Преподаватель нажимает кнопку «К результатам».

А3.2 Система выводит страницу «Результаты тестирования по предмету». На экран выводится таблица, содержащая строки, в которых содержится имя студента, дата и время прохождения теста и ссылка на отчет по тестированию.

А3.3 Преподаватель выбирает интересующую его строку и нажимает на ссылку на отчет.

А3.4 Система выводит на экран страницу с отчетом по результатам тестирования.

А3.5 Преподаватель просматривает отчет и нажимает кнопку «Назад». Система выводит страницу «Результаты тестирования по предмету». Вариант использования завершается.

А4 : Редактирование теста

А4.1 Система выводит страницу «Редактирование теста по предмету», содержащую форму редактирования теста, аналогичную форме добавления нового теста, заполненную актуальными данными из БД.

А4.2 Преподаватель редактирует нужные поля формы и нажимает кнопку «Отправить».

А4.3 Система сохраняет введенные данные, закрывает страницу «Редактирование теста по предмету» и выводит на экран страницу «Тесты по предмету». Вариант использования завершается.

Сценарий 2

Вариант использования: Прохождение теста по предмету текущего семестра

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

Актор: Студент

Предусловия: Компьютер включен, система загружена, выполнен вариант использования «Вход в систему» с правами Студента. На экране загружено главное окно программы с пунктами меню: "Рекомендации", «Тесты», «Успеваемость», «Справка», «Выход»;

Основной поток событий

1. Студент выбирает пункт меню «Тесты».

2. А4: Выход

3. Система выводит список доступных тестов.

4. Студент выбирает нужный тест из списка и нажимает на кнопку «Пройти тест».

5. А5: Закрытие страницы

6. Система выводит на экран текст вопроса и варианты ответов

7. Студент читает текст вопроса и выбирает один или несколько ответов из списка предложенных ответов и нажимает кнопку «Далее». Пункты 4) и 5) выполняются до тех пор, пока студент не ответит на все вопросы данного теста.

8. А5: Закрытие страницы

9. А6: Завершение теста

10. Система подсчитывает количество правильных ответов, сохраняет результаты прохождения теста и выводит результат прохождения на экран.

11. Студент ознакамливается с результатами прохождения теста и нажимает кнопку «Готово».

12. А5: Закрытие страницы

13. Система закрывает текущую страницу и выводит на экран главную страницу приложения с пунктами меню, настроенными на права Студента. Вариант использования завершается успешно.

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

A1: Выход

А1.1 Студент выбирает пункт меню «Выход»

А1.2 Система сбрасывает данные авторизации пользователя и выводит страницу ввода логина и пароля. Вариант использования завершается

А2: Закрытие страницы

А2.1 Студент нажимает кнопку «Закрыть».

А2.2 Система осуществляет выход в окно операционной системы, закрывая приложение. Вариант использования завершается.

А3: Завершение теста

А3.1 Студент нажимает кнопку «Завершить тест».

А3.2 Система выводит диалоговое окно с текстом сообщения «Вы уверены?» и кнопками выбора ответа «Да» и «Нет».

А3.3 Студент нажимает кнопку «Да».

А3.4 Система закрывает диалоговое окно. Система завершает процесс тестирования, сохраняет данные о завершении теста и выводит главную страницу. Вариант использования завершается.

1.6 Диаграмма классов

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

Класс имеет имя, списки атрибутов, операций или методов.

Операция - спецификация (описание) результата преобразования или запроса, которые должен выполнить вызываемый объект. Имеет имя и список параметров.

Метод - процедура, непосредственно реализующая операцию; у нее есть алгоритм и описание процедуры. Обычно метод задаётся на физическом уровне представления класса в модели проектирования, когда уже выбран алгоритм и способ его реализации.

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

Классы могут находиться между собой в различных отношениях (связях).

Классы по своей роли в системе делятся на группы:

- классы управления: объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п. Диаграмма сущностных классов представлена на рисунке 1.6;

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

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

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

Класс «Менеджер приложений» отражает основные функции для организации работы приложения.

Класс «Менеджер СУБД» представляет собой функции для обработки запросов к базам данных.

Класс «Менеджер печати» представляет собой функции для организации печати данных

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

Диаграмма состояний (state chart diagram) - диаграмма, на которой изображается конечный автомат с простыми состояниями, переходами и, возможно, вложенными композитными состояниями. Диаграмма состояний описывает процесс изменения состояний одного или нескольких экземпляров классов, т.е. моделирует все возможные изменения в состоянии конкретного объекта, которые вызваны внешними воздействиями со стороны других объектов или извне. Диаграмма состояний представляет динамическое поведение сущностей на основе спецификации их реакции на восприятие некоторых конкретных событий. Главное назначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. В основе диаграммы состояний лежит автоматическая модель. Основные свойства модели:

- Переходы из состояния в состояние считаются мгновенными.

- Одновременный переход в несколько состояний невозможен.

- Каждое состояние должно быть достижимым.

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

- Количество состояний не бесконечно, а конечно в автомате.

Переход из состояния в состояние возможен при следующих условиях:

- Завершены все действия и деятельности в исходном состоянии, если не поступал сигнал прерывания.

- Выполнено сторожевое условие, если оно есть.

- Выполнено действие, прикрепленное к переходу, если оно есть.

- Произошло переключающее событие типа посылки сигнала или изменения какого-либо условия.

Диаграмма состояний для разрабатываемой системы представлена на рисунке 1.9. Она отражает общую работу с приложением.

1.8 Логическая структура базы данных

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

Логический уровень позволяет давать объектам имена более понятные специалистам предметной области.

Логическая схема базы данных представлена на рисунке 1.10.

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

2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.6

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

Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.

По степени распределенности выделяют два типа:

- Настольные. Все компоненты находятся на одной ЭВМ;

- Распределенные. Компоненты находятся на разных ЭВМ.

В свою очередь, в распределенном типе архитектуры выделяют следующие подтипы [14]:

- Файл-серверная архитектура (рисунок 2.1). Схожа с настольной архитектурой за одним существенным исключением - используются сетевые ресурсы для хранения данных и программы.

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

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

Слой представления

Пользовательский интерфейс

Слой бизнес-логики

Бизнес-логика,

Обращение к СУБД

Слой доступа к данным

Выполнение операторов

Хранение и управление данными

Клиент

Сервер

Рисунок 2.1 - Схема файл-серверной архитектуры

- Двухуровневая клиент-серверная архитектура (рисунок 2.2).

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

-

Слой представления

Пользовательский интерфейс

Слой бизнес-логики

Обращение к СУБД, бизнес-логика

Выполнение процедур

Слой доступа к данным

Выполнение запросов,

Хранение и управление данными

Клиент

Сервер

Рисунок 2.2 - Схема двухуровневая клиент-серверной архитектуры

- Переходная к трехуровневой архитектуре.

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

- Трехуровневая клиент-серверная архитектура (рисунок 2.3).

- Основным отличием этой архитектуры является разделение серверного программного обеспечения на две части: программы, отвечающей за хранение данных (сервер СУБД) и программы, отвечающей за их обработку и предоставление функций клиентскому ПО (сервер приложений). Это позволяет достигнуть максимальной масштабируемости ИС, упростить обновление любого звена архитектуры или его замену с минимальными расходами для других уровней. Бизнес логика полностью переносится на сервер приложений и сервер СУБД, клиент отвечает только за представление интерфейса пользователя и вызов функций сервера приложений.

Слой представления

Пользовательский интерфейс, вызов функций сервера приложений

Слой бизнес-логики

Выполнение функций,

запросы к серверу СУБД

Выполнение процедур

Слой доступа к данным

Выполнение запросов,

Управление данными

Клиент

Сервер приложений

Сервер СУБД

Рисунок 2.3 - Схема трехуровневая клиент-серверной архитектуры

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

Язык программирования

PHP -- интерпретируемый язык общего назначения, как правило применяемый для разработки веб-приложений [15]. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков, применяющихся для создания динамических веб-сайтов. Язык и его интерпретатор разрабатываются группой энтузиастов в рамках проекта с открытым кодом.

Проект активно развивается, в данный момент актуальна версия 5.6, идет разработка PHP7. TIOBE Index является индикатором популярности языков программирования и основывается на количестве квалифицированных инженеров в мире, обучающих курсах и сторонних поставщиков ПО на конкретном языке. Согласно данным TIOBE Index, на май 2015 года PHP находится на 6 месте в мире [16].

Язык обладает слабой динамической типизацией.

Возможно применение как функционального, так и объектно-ориентированного программирования.

Кроссплатформенность резко снижает требования к запуску программ: для работы программы, написанной на PHP достаточно наличия интерпретатора для конкретной ОС.

СУБД

MySQL -- свободная реляционная система управления базами данных.

Эта кроссплатформенная СУБД поддерживает несколько различных типов таблиц (InnoDB, MyISAM и др.), транзакции, внешние включи, триггеры, курсоры и многое другое.

Распространяется как в свободном, так и коммерческом варианте. Возможно использование как в виде отдельного сервера, к которому обращаются клиенты, так и встраивание библиотеки внутреннего сервера в автономное ПО.

MySQL имеет API для большинства языков программирования; кроме того обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

Многие крупные международные компании используют MySQL в своем программном обеспечении: Facebook, Google, Adobe, Alcatel Lucent.

Причины для использования MySQL:

- Высокая производительность. Вне зависимости от назначения системы.

- Низкий порог вхождения. Установка по сложности не отличается от установки любой другой программы. После установки СУБД готова к работе - не требуется обязательной настройки.

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

Операционная система

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

В логической структуре ЭВМ операционная система находится между физическими устройствами и их микропрограммами с одной стороны и прикладными программами с другой.

Использование в разрабатываемой ИС кроссплатформенных инструментов и технологии «тонкого» клиента позволяет не привязывать её к конкретной ОС. Клиент может обладать любой ОС, в которой есть программа типа «веб-браузер» с поддержкой JavaScript и HTML5, к примеру Windows, MacOS, Linux, Android и т.д. Сервер - Windows, MacOS, Linux.

2.8

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

Для ER-модели существует алгоритм однозначного преобразования ее в реляционную модель данных

Рассмотрим правила преобразования ER-модели в реляционную.

- Каждой сущности ставится в соответствие отношение реляционной модели данных. При этом имена сущности и отношения могут быть различными, потому что на имена сущностей могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. Имена отношений могут быть ограничены требованиями конкретной СУБД, чаще всего эти имена являются идентификаторами в некотором базовом языке, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов. Например, сущность может быть названа "Книжный каталог", а соответствующее ей отношение желательно назвать, например, BOOKS (без пробелов и латинскими буквами).

- Каждый атрибут сущности становится атрибутом соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование отношений в п.1. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута

- Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности ( NOT NULL )

- В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом ( FOREIGN KEY )

- Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL)

- Разрешение связей типа «многие-ко-многим». Так как в реляционной модели данных поддерживаются между отношениями только связи типа «один-ко-многим», а в ER-модели допустимы связи «многие-ко-многим», то необходим специальный механизм преобразования, который позволит отразить множественные связи, неспецифические для реляционной модели, с помощью допустимых для нее категорий. Это делается введением специального дополнительного связующего отношения, которое связано с каждым исходным связью «один-ко-многим» [18].

Таблица 2.1 - Соответствие физического и логического уровней

Физический уровень

Логический уровень

Поле

Тип данных

nox_user

Пользователь

id

int

login

varchar

password

varchar

name

varchar

registration_date

datetime

last_visit

datetime

nox_group

Группы_пользователей

id

int

name

varchar

nox_user_groups

Группы_пользователя

user_id

int

group_id

int

recommendation

Рекомендация

id

int

lecture_id

int

text

varchar

date_add

datetime

recommendation_student

Рекомендации_студента

recommendation_id

int

student_id

int

date_add

datetime

test

Тест

id

int

name

varchar

lecture_id

int

duration

int

description

text

test_question

Вопросы_теста

id

int

test_id

int

question

text

test_question_variable

Ответы_вопроса_теста

id

int

question_id

int

is_right

boolean

text

text

test_result

Результаты_тестирования

id

int

test_id

int

student_id

int

data

text

test_student

Тесты_студента

test_id

int

student_id

int

learn_faculty

Факультет

id

int

name

varchar

learn_faculty_group

Группы_факультета

id

int

faculty_id

int

name

varchar

date_start

date

learn_lecture

Предмет

id

int

name

varchar

learn_semester

Семестр

id

int

name

varchar

date_start

date

date_end

date

learn_student

Студент

id

int

group_id

int

surname

varchar

name

varchar

patronymic

varchar

learn_teacher

Преподаватель

id

int

surname

varchar

name

varchar

patronymic

varchar

group_lecture

Учебные_предметы_группы

id

int

lecture_id

int

group_id

int

teacher_id

int

semester_id

int

group_lecture_student

Результаты_обучения

group_lecture_id

int

student_id

int

mark

int

Для разработки физической структуры БД (рисунок 2.3) использовался инструмент MySQL Workbench. Он является визуальным инструментом для архитекторов, разработчиков и администраторов баз данных. MySQL Workbench обеспечивает моделирование данных, разработку SQL и комплексные средства администрирования для настройки сервера, управление пользователями, резервное копирование, разработку ERP-диаграмм и многое другое. MySQL Workbench доступен на Windows, Linux и Mac OS X [19].

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

2.9

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

2.9.1

Расчет необходимого объема внешней памяти

Для расчета внешней памяти воспользуемся формулой (2.1):

, Мбайт (2.1)

- общий объём внешней памяти;

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

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

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

- объём внешней памяти, необходимый для хранения информации.

В качестве ОС выберем Windows 7 (x64):

= 20840 Мбайт[20];

= 20 Мбайт.

= 40 Мбайт;

= 200 Мбайт (включая веб-сервер Apache 2, Perl, PHP);

Сложив данные, получим:

= 20840+20+40+200= 21100 Мбайт.

Таким образом, для сервера нам потребуется жесткий диск

объемом 22 Гб.

Расчет необходимого объема оперативной памяти

Формула, используемая для расчета требуемой оперативной памяти, аналогична формуле (2.1).

= 2048 Мбайт[20];

+ = 64 Мбайт

= 71 Мбайт.

= 2048 +64+71=2183 Мбайт.

Объем оперативной памяти для СУБД и программы рассчитан исходя из пикового использования оперативной памяти этими программными процессами на основе данных системного приложения «Диспетчер задач Windows»

Поскольку оперативная память комплектуется модулями стандартного размера от 128 до 8096 Мбайт, мы выбираем один модуль на 2048 Мбайт и один модуль 256 Мбайт для сервера. При невозможности установки двух модулей ОЗУ, мы выбираем один модуль на 4096 Мбайт.

Расчеты характеристик для клиента:

= 0 Мбайт;

= 0 Мбайт;

= 1024 Мбайт.

= 320 Мбайт;

= 1024 + 320=1354 Мбайт.

рассчитывался исходя из пикового объема памяти, используемого веб-браузером Google Chrome при отображении веб-клиента ИС на основе данных системного приложения «Диспетчер задач Windows»

Поскольку оперативная память комплектуется модулями стандартного размера от 128 до 8096 Мбайт, мы выбираем один модуль на 2048 Мбайт для клиента.

Расчет времени реакции системы

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

Общее время реакции системы на выполнение запроса рассчитывается по формуле (2.2):

(2.2)

,

,

,

,

.

- время на ввод входных данных запроса;

- коэффициент ошибок при вводе, для расчетов можно принять равным 1,5;

- количество символов, вводимых в качестве исходных данных запроса.

- время ввода одного символа, при ручном вводе с клавиатуры в некоторую экранную форму можно принять в среднем равным 2 с;

- время, затрачиваемое на считывание физических блоков при работе с накопителем;

- количество считываемых физических блоков, зависит от количества обрабатываемых таблиц (файлов) и объема таблиц (файлов);

=0,006 сек - время позиционирования головок дискового накопителя;

=0,001 сек - время считывания физического блока в дисковом накопителе;

- время, затрачиваемое процессором на обработку информации с учетом выполнения циклов;

= 10 000 - количество операций высокого уровня, необходимых для формирования результата;

- среднее количество тактов машинных команд на одну операцию, для большинства случаев можно принять = 60;

= 1600*106 - тактовая частота процессора, Гц;

= cредний объем таблицы, байт;

= 3 - количество таблиц, обрабатываемых в запросе;

= 512 байт - объем физического блока носителя, байт;

- время на вывод результата на устройство вывода или отображения, для принтера оценивается отдельно. Для дисплея можно принять 0,5 с. (зависит от видеокарты и дисплея).

Результаты расчета времени реакции системы приведены в таблице 2.2.

Таблица 2.2 - Расчет времени реакции системы

Параметр

Значение

Vтабл=

2048

Nбл=

1600

tввода= (секунд)

0

tсчитыв= (секунд)

0.6

tвычисл= (секунд)

8.0

tреакции=(секунд)

0.76

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

Требования к комплексу технических средств

Сервер:

- процессор класса Core2Duo с тактовой частотой 1,8 ГГц и выше;

- рекомендуемый объем оперативного запоминающего устройства (ОЗУ) 2300 Мбайт;

- жесткий диск емкостью не менее 22 Гбайт.

Клиент:

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

- рекомендуемый объем оперативного запоминающего устройства (ОЗУ) 2048 Мбайт;

- жесткий диск емкостью не менее 22 Гбайт;

- любой видеоадаптер с возможностью вывода комфортного разрешения для пользования системой - не менее 1024х768.

2.10

1.11 Диаграмма последовательности

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

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

В UML диаграмма последовательности имеет как бы два измерения. Первое слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия. Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый очередностью или степенью активности объектов при взаимодействии друг с другом.

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

Вторым измерением диаграммы последовательности является вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. Взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения, а их порядок определяется временем возникновения. То есть, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. Масшт...


Подобные документы

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