Замечание: Подробнее о формате файлов РВУ Вы можете прочитать в «Руководстве Администратора»

Данные пользователя. Форма 2.

1. 1. Имя;

2. Отчество;

3. Фамилия;

4. Почтовый индекс;

5. Край / регион;

6. Город;

7. Улица;

8. Номер дома, квартиры;

9. Email;

10. Телефон (не обязательно).

4. Разработка информационного обеспечения задачи

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

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

4.1 Информационный анализ предметной области и выделение информационных объектовзадачи.

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

Рассмотрим информацию, содержащуюся в форме регистрации пользователя (Форма 2). В ней содержатся реквизиты, общие для всей формы. Причем каждый из них имеет единственное значение. Среди этих реквизитов особую роль играет e-mail пользователя. Поскольку этот реквизит уникален, то есть его значение не может повториться, он играет роль идентификатора всей информации по пользователю, содержащейся в форме. Остальные реквизиты однозначно определяются e-mail'ом пользователя. Помимо полученных от пользователя данных необходимо учитывать дату и сам факт регистрации, т.е. оплаты права на пользование услугами и выдачи пользователю логина и пароля. В целях экономии дискового пространства нужно завести реквизит уникальный номер пользователя, который будет связывать информацию о пользователе, о его логине/пароле и “истории” прохождения тестов. На основе проведенного анализа установим функциональные зависимости реквизитов регистрационной формы и отобразим их в таблице 2.

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

Таблица 1. Функциональные зависимости реквизитов формы создания нового теста.

Таблица 2. Функциональные зависимости реквизитов формы регистрации

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

Данные статистики. Форма 3.

1. Идентификатор пользователя, проходившего тест;

2. идентификатор теста;

3. результат (количество баллов);

4. дата прохождения теста;

5. идентификатор задачи;

6. правильность ответа на задачу.

Данные о правах пользователя на тест. Форма 4.

1. Идентификатор пользователя;

2. идентификатор теста;

3. код доступа; (0 - не подписан, 1 - подписан, 2 - тест сдан)

Установим функциональные зависимости реквизитов, учитывая, что один и тот же пользователь может пройти различные тесты с различными результатами. Следовательно, эти данные не уникальны, кроме реквизита дата, при условии, что пользователь не может успеть физически пройти более одного теста за одну минуту (табл. 3).

Таблица 3. Функциональные зависимости реквизитов данных статистики.

Таблица 4. Информация о правах пользователя на тест

Выделение информационных объектов.

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

Таблица 5. Соответствие описательных и ключевых реквизитов.

* ИО - информационный объект.

Таблица 6. Реквизитный состав информационных объектов.

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

4.2 Определение связей информационных объектов и построение ИЛМ.

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

Таблица 7. Связи информационных объектов.

Графическое изображение ИЛМ, наглядно показывающей иерархические отношения подчиненности информационных объектов, приведено на рис. 1.

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

4.3 Определение логической структуры реляционной базы данных.

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

Логическая структура реляционной базы данных, построенная на основе полученной ИЛМ, приведена в Приложении 1. На этой схеме реляционные таблицы представлены структурой, определяемой составом и последовательностью полей (атрибутов). Ключевые поля отмечены знаком . Логические связи изображены линиями между одинаковыми ключами связи.

4.4 Исходные данные контрольного примера.

В качестве контрольного примера служит «Гостевой вход» и «пробный тест».

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

Таблица 8. Данные Test_Com.

Таблица 9. Данные Tests.

Таблица 10. Данные Tasks

Таблица 10. Данные Answ

Примечание: Таблицы UserReg, UserLog, History, TheHistory в данном примере не задействованы.

5. Разработка алгоритмов и технологии решения задачи

Общие сведения о содержании и алгоритме решения задачи.

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

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

5.1 Технология ввода и накопления входной информации, обеспечивающей решение задачи.

Для решения рассматриваемой задачи должен производиться ввод и накопление в БД оперативно-учетной информации о тестах и пользователях. Справочная информация должна хранится в html-файлах на сайте.

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

5.2 Определение макета форм ввода-вывода

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

Форма для загрузки данных о пользователе при регистрации (см. форму 5) является простой однотабличной. Форма строится на базе таблицы UserReg, в которую и будут загружаться соответствующие поля. При внесении в базу данных о новом пользователе необходимо установить поле Registered в 0. Если пользователь получит разрешение на прохождение, то этот поле поменяем на 1. Поле Id будет заполняться автоматически при добавлении записи в таблицу.

Макет формы ввода данных о пользователе при регистрации. Форма 5.

Для загрузки данных в таблицу UserLog и изменения записи в таблице UserReg будем использовать форму выдачи пользователю логина и пароля (форма 6). Эта форма связана с предыдущей формой по ключевому полю Id. После выдачи логина и пароля пользователю необходимо изменить поле Registered записи о нем в таблице UserReg с 0 на 1.

Макет формы выдачи пользователю логина и пароля. Форма 6

Выдать

Для входа в систему нужна форма, принимающая логин и пароль пользователя для проверки их в базе данных (форма 7). Это простая форма, связанная с таблицей UserLog полями Login и Pwd.

Макет формы идентификации. Форма 7

Для добавления нового теста в базу данных используется форма 8. Ей необходимо указать только имя файла с добавляемым тестом. Формат файла определен выше. Эта форма наполняет и связывает таблицы TestCom, Tests, Tasks, Answ.

Макет формы добавления нового теста. Форма 7

5.3 Обобщенный алгоритм решения задачи и его декомпозиция на модули (функции)

Из рисунка 2 видна общая декомпозиция задачи на модули. Рассмотрим систему тестирования пользователя. При входе в систему пользователь вводит свой логин и пароль. По этим данным из базы данных необходимо получить уникальный номер пользователя (Id), этот номер, в свою очередь, будет передан тестирующему модулю системы вместе с уникальным номером теста (Test_Un), запрошенного пользователем. Отображать вопросы (задачи) теста будем дозировано, т.е. по одной задаче за раз.

Функционально-технологическая схема и алгоритм тестирования.

Рис. 3. Общая функционально-технологическая схема подсистемы тестирования

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

Рис. 4. Блок-схема алгоритма подсистемы тестирования

5.4 Детальные алгоритмы реализации отдельных модулей задачи

Модуль 1.1. Проверка логина и пароля.

На входе имеем: login - логин пользователя, password - пароль пользователя.

Посылам запрос к SQL серверу:

SELECT * FROM UserReg, UserLog WHERE Login = `login' AND Pwd = `password' AND UserReg.Id = UserLog.Id

Если результат запроса не пустой, то считаем, что пользователь авторизовался успешно, также в результате запроса имеем все его данные - ФИО, адрес, …

На входе имеем: Test_Un - номер теста, который выбрал пользователь для прохождения.

Посылам запрос к SQL серверу:

SELECT Task_Un FROM Tests WHERE Test_Un = Test_Un

Необходимо узнать, сколько задач нужно выдать пользователю.

Посылам запрос к SQL серверу:

SELECT Test_Portion FROM TestCom WHERE Test_Un = Test_Un

Результат запомним в Portion. «Перемешиваем» массив задач, полученный на предыдущем шаге, и оставляем только Portion из них.

На входе: Task_Un - номер задачи, для которой выбираем ответы.

Посылам запрос к SQL серверу:

SELECT * FROM Answ WHERE Task_Un = Task_Un

На входе: Task_Un - номер задачи, текст которой нужно вывести. Answers - массив вариантов ответов для этой задачи.

Посылам запрос к SQL серверу:

SELECT Task_Cont FROM Tasks WHERE Task_Un = Task_Un

Результат - тело задачи в формате HTML, его и выводим.

Результат - тело варианта ответа в формате HTML, его и выводим.

На входе: Answer - номер ответа, который выбрал пользователь.

Посылам запрос к SQL серверу:

SELECT Answ_True FROM Answ WHERE Answ_Un = Answer

Результат - 0 (не правильный) или 1 (правильный) ответ. Этот результат заносим в таблицу History и храним до конца теста.

После того, как пользователь ответит на все предложенные вопросы, нужно посчитать, сколько раз он ответил правильно (n), и сколько всего вопросов было (m). После чего выводим итог: «Ваш результат n баллов из m».

6. Руководство администратора

6.1 Системные и технические требования

Для работы системы необходимо наличие следующего программного обеспечения на сервере:

· OS Windows (Server Family);

· MSSQL Server 7.0 или выше;

· Apache Win32 / PHP 4.0 или выше;

Вместо Apache можно использовать и другой веб-сервер, например MS IIS, единственное требование - поддержка PHP хотя бы на уровне CGI.

6.2 Подготовка к работе

6.2.1 Подготовка веб-сервера

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

%Apache%/htdocs/do/, где %Apache% - установочный каталог веб сервера.

Далее все пути на диске будут указываться относительно каталога %Apache%/htdocs/.

6.2.2 Подготовка базы данных.

1. Создаем в MSSQL Server базу данных и называем ее DO.

2. В базе данных DO создаем пользователя с логином do_user и паролем www123 . Естественно, что пароль стоит выбрать более сложный. Эти данные - пример.

3. Логин и пароль для доступа к базе данных используются в файле do/bin/admin/register.php

4. Создаем в базе DO хранимую процедуру CreateAllTables, текст которой можно посмотреть в файле do/tsql/CreateAllTables.sql, и выполняем эту процедуру. В результате создадутся все необходимые для работы системы таблицы.

5. Создаем в базе DO хранимую процедуру DropAllTables, текст которой можно посмотреть в файле do/tsql/DropAllTables.sql. Результатом этой процедуры будет полное удаление всех таблиц, созданных процедурой CreateAllTables, и дынных в них. Сейчас эту процедуру выполнять не нужно. Она нужна при удалении системы.

6. Для добавления тестов по физике, необходимо создать в базе DO ряд хранимых процедур, тексты которых приведены в файлах вида do/tsql/phys/nn_CreateTestXXX.sql , где nn - номер теста; XXX - сокращенное название теста.

7. Создаем хранимую процедуру CreateAllTests (do/tsql/phys/ CreateAllTests.sql), которая создаст 17 тестов по физике: 1 пробный, 15 тренажерных и 1 экзаменационный.

8. Создаем процедуру DeleteAllTests (do/tsql/phys/DeleteAlllTests.sql), которая удаляет все, созданное процедурой CreateAllTests.

9. Теперь необходимо дать права пользователю базы данных do_user на операции SELECT, UPDATE, INSERT, DELETE во всех таблицах, созданных процедурой CreateAllTables.

6.3 Вход в систему

На сайте системы выбираем раздел «Вход». Появится форма как на рисунке 1.

В появившейся форме авторизации вводим логин и пароль администратора. Эти данные хранятся не в базе данных, а в файле do/bin/user/logon.php, для того, чтобы администратор смог авторизоваться, даже если база данных не доступна.

Рис. 1. Форма авторизации

В случае успешной авторизации появится меню Администрирование:

· Просмотр таблиц пользователей

o Посмотреть таблицу UserReg (просмотр всех зарегистрированных пользователей)

o Посмотреть таблицу UserLog (просмотр всех пользователей, подавших заявку на регистрацию)

· Работа с пользователями

o Добавить пользователя в UserLog (зарегистрировать пользователя, подавшего заявку на регистрацию)

o Подписать пользователя на тест (дать доступ пользователю к определенному тесту)

o Удалить пользователя (удалить пользователя из системы вместе со всей историей прохождения тестов)

o Удалить «просроченных» пользователей (как предыдущий пункт, но для пользователей, которые находятся в системе больше месяца)

· Тесты

o Добавить новый тест

o Создать тесты Калистратовой (создать тесты по физике, которые были описаны в процедуре CreateAllTests)

o Удалить тесты Калистратовой (соответственно DeleteAllTests)

· Статистика

o По тестам (кем и когда проходился определенный тест)

o По пользователям (какие тесты и когда проходил определенный пользователь)

o Список всех пользователей (список ФИО, логин, пароль)

6.4 Просмотр таблиц пользователей

Выбрав пункт меню администратора «Посмотреть таблицу UserReg», можно посмотреть таблицу UserReg, в которой находятся все данные о пользователях: ФИО, адрес, e-mail, телефон и т.д. как на рис. 2.

Рис. 2. Данные таблицы UserReg.

Выбрав пункт меню администратора «Посмотреть таблицу UserLog», можно посмотреть таблицу UserLog, в которой представлена информация о зарегистрированных пользователях: логин, пароль, дата регистрации как на рис. 3.

Рис. 3. Данные таблицы UserReg.

6.5 Работа с пользователями

6.5.1 Общие положения

Когда пользователь заполняет форму регистрации и нажимает кнопку «Отослать», ему приходит подтверждение в виде письма на указанный e-mail. Дальше пользователь ждет, когда его зарегистрирует администратор и вышлет логин и пароль для входа в систему.

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

По умолчанию пользователь не имеет доступа ни к каким тестам системы. Для того, чтобы пользователь получил доступ к тесту, его (пользователя) необходимо «подписать» на этот тест. После того, как пользователь прошел тест, он снова теряет доступ к нему.

6.5.2 Регистрация пользователя.

В меню администратора выбираем пункт «Добавить пользователя в UserLog». Появится форма как на рис. 4.

Рис. 4. Форма поиска пользователей.

В приведенной форме можно ввести данные пользователя, чтобы его было легче найти, или оставить все поля пустыми. Нажимаем кнопку «Найти». Появится список всех (если поля формы остались пустыми) пользователей, которые в данный момент ожидают регистрации (рис. 5)

Рис. 5. Выбор пользователя для регистрации его в системе.

Необходимо выбрать одного из них, указать его логин и пароль и нажать на кнопку «Зарегистрировать». После чего система посылает письмо пользователю с подтверждением факта регистрации и его данными для входа в систему.

6.5.3 Подписка пользователя на тест

В меню администратора выбираем пункт «Подписать пользователя на тест». В появившейся форме (рис. 4) можно ввести данные пользователя, чтобы его было легче найти, или оставить все поля пустыми. Нажимаем кнопку «Найти». Появится список всех (если поля формы остались пустыми) пользователей, которые зарегистрированы в системе (рис. 6).

Рис. 6. Выбор пользователя для «подписки» на тест

Выбираем одного пользователя и нажимаем «Подписать». Появится список тестов, на которые можно подписать выбранного пользователя. Если пользователь уже подписан на этот тест, то напротив названия таста будет пометка - «подписан» (если тест сдан, то пометка - «сдан») как на рис. 7.

Рис. 7. Выбор теста(ов), на который(е) нужно подписать пользователя.

Отмечаем нужные тесты и нажимаем «Подписать». После этого пользователь получает доступ к выбранным тестам.

6.5.4 Удаление пользователя

В меню администратора выбираем пункт «Удалить пользователя». В приведенной форме (рис. 4) можно ввести данные пользователя, чтобы его было легче найти, или оставить все поля пустыми. Нажимаем кнопку «Найти». Появится список всех (если поля формы остались пустыми) пользователей, которые зарегистрированы в системе. Выбираем одного пользователя и нажимаем «Удалить». После этого пользователь полностью удален из системы со всей историей прохождения тестов.

6.5.5 Удаление «просроченных» пользователей

В меню администратора выбираем пункт «Удалить просроченных пользователей». Появится список всех зарегистрированных пользователей, которые были зарегистрированы в системе более месяца назад.

Рис. 8. Удаление «просроченных» пользователей

Нажатие кнопки «Удалить» приведет к удалению (как в пункте выше) всех «просроченных» пользователей.

6.6 Работа с тестами

6.6.1 Формат тестов РВУ

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

Первая строка файла должна содержать имя группы вопросов.

Формат строки: имя группы вопросов.

Примечание: в случае, если такая группа уже существует, то вопросы будут к ней добавлены.

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

Примечание: в строках блока, описывающих характеристики вопроса, перед каждым полем обязательно устанавливается указатель поля «<$:».

Система РВУ поддерживает следующие форматы вопросов:

1. Выбор из списка единственного правильного ответа;

2. Выбор из списка нескольких правильных ответов;

3. Ввод некоторых данных, которые впоследствии будут сравнены с заложенным "эталоном"

4. Ответ на естественном языке;

5. Последовательность.

В случае необходимости могут быть заданы дополнительные форматы (после согласования с Консалтинговым центром РСОО).

В каждом блоке должно быть описано несколько обязательных для любого формата вопросов строк:

· Формат строки:--/New Question/--

· Назначение: указывает на начало блока информации о вопросе.

· Примечание: любой вопрос должен начинаться этой строкой.

· Формат строки: <$:QuestionType:N

· Назначение:описывает поле QuestionType, которое задает вариант формата заносимого вопроса в виде натурального числа N из диапазона [1, 5].

· Примечание:форматы вопросов разрабатываются в Консалтинговом центре РСОО.

· Формат строки: <$:QuestionBody: текст вопроса.

Назначение: описывает поле QuestionBody, которое содержит формулировку основного задания (условия) вопроса.

Примечание:указывается в одну строку (макс. 64000 символов).

· Формат строки: <$:Difficulty:N

· Назначение: описывает поле Difficulty, которое отражает сложность вопроса.

· Примечание:сложность вопроса задается в виде числа N, где N - натуральное число из диапазона [1, 10].

· Форма...