Автоматизация сбора данных. Результаты тестирования Внедрение системы
 Скачать 5.77 Mb.
|
4.3 Проектирование структур данных и алгоритмов4.3.1 Общий алгоритм программыСловесно описать общий алгоритм программы можно следующим образом: 1) Получение данных от пользователя. 2) Проверка данных на корректность. 3) Составление листа запросов. 4) Произведение опроса нужных ресурсов согласно листу. a) На каждом шаге – получение данных с требуемых ресурсов. b) Обработка полученных данных. 5) Составление рейтинга на основе всех результатов. 6) Вывод результатов в отчет. 4.3.2 Алгоритм работы отдельных стадий выполнения программыПервая стадия, это взаимодействие с пользователем – предоставление ему интерфейса для удобной работы с программой, реакция на его действия в интерфейсе (реакция на события), проверка введенных им данных и составление на их основе структур для составления в будущем запросов к ресурсам. Важным в этой стадии является то, что в ней необходимо минимизировать вероятность занести ошибку пользователем. Поэтому разработаем алгоритм проверки корректности введенных данных: 1) Проверка соответствия количества указанных баллов, количеству задач. 2) Проверка наличия идентификаторов у инспектируемых студентов для заданных ресурсов. 3) Проверка корректности ИД (только цифры). 4) Проверка корректности номеров задач (только цифры и запятые). 5) Проверка корректности баллов (только цифры и запятые). 6) Проверка наличия временного интервала. 7) Проверка наличия задач и их источников. Если ПП обнаружит ошибку в данных, то выведет окно со списком найденных ошибок. Пока пользователь их не исправит, он не сможет получить отчет. Второй стадией является составление списка запросов, которые ПП будет отправлять требуемым ресурсам: 1) Составление общего списка задач и инспектируемых студентов. 2) Создание данных для запроса (один запрос хранит в себе ИД, ресурс, номер требуемой задачи). 3) Запись запроса в лист запросов. Третья стадия – получение результатов на основе листа запросов, на ней производятся следующие действия: 1) Перебирая лист запросов, вызываем требуемый ресурс, передав ему данные для запроса. 2) Получаем страницу, передаем её соответствующему парсеру. 3) Получаем от парсера лист с результатами по текущей задаче. 4) Заносим этот лист в хеш таблицу, где ключ ФИО, следующий ключ это номер задачи с префиком (зависит от источника). Четвертая стадия – анализ полученных данных. В нем определяется, решил ли пользователь задачу, количество попыток ее решения, уложился ли он в заданный временной интервал. На выходе получаем: 1) Хеш-таблицу с задачами, решенными в срок. 2) Хеш-таблицу с задачами, решенными вне срока. 3) Хеш-таблицу с количеством попыток. 4) Хеш-таблицу с общим количеством полученных баллов (если рейтинг составляется на их основе). 5) Лист инспектируемых студентов, отсортированный согласно занятому ими по результатам решения задач месту. 6) Хеш-таблицу с местом конкретного участника (на случай если кол-во баллов или решенных задач одинаково, одного отсортированного листа будет недостаточно). И завершающая стадия – это составление отчета, на основе данных, полученных на четвертой стадии. Здесь алгоритм работы следующий: 1) Получаем шаблон отчета. 2) Подготавливаем шаблон – вставляем номера задач с префиксом в качестве заголовков столбца. 3) Идя по списку участников: a) Вставляем его результат по каждой задаче (кол-во попыток, итог решения), количество суммарных баллов, место. 4) Сохраняем отчет в том месте, где указывает пользователь. 4.3.3 Проектирование основных классовПарсеры. У парсеров есть общий класс родитель, он содержит в себе общие для всех парсеров методы и поля. Сам механизм извлечения нужных данных из html страниц у каждого парсера свой. На выходе они должны давать лист результатов. Также для сайта кафедры есть еще один парсер, извлекающий баллы по каждой задаче. Классы составления GET запросов к сайтам. У этих классов есть общий родитель, с методом, возвращающим строку GET запроса на основе данных для этого запроса Каждый конкретный класс работает с определенным сайтом. Внутри себя хранит шаблон для составления GET запроса. Он устанавливает данные для запроса в нужные параметры и возвращает уже готовый GET запрос. Класс сбора результатов по сайтам. Класс получает список данных для запросов, передает им соответствующим классам составления Get запроса и устанавливает соединение по полученной от них ссылке. Полученную от сайтов страницу передает нужному парсеру, получает от него список результатов. Из них формирует таблицу результатов. Класс анализа полученных результатов. Это важный класс – он будет заполнять структуры, описанные в четвертой стадии работы программы. Класс составления отчета может с легкостью обращаться к этим структурам, на их основе он и строит свой отчет. Класс составления отчета. Работает с шаблоном отчета. В его функционал входят задачи: 1) Подготовка шаблона (выставление заголовков задач с префиксом). 2) Выставление для каждого испытуемого его результатов. 3) Выдача отчета в виде строки. 4.4 Проектирование пользовательского интерфейсаОпираясь на решаемую ПП задачу, обозначим тот набор данных, который потребуется ей от пользователя, чтобы её решить. Прежде всего, это: ФИО инспектируемых студентов для вставки в отчет. Их ИД на требуемых ресурсах. Номера задач с указанием источника. Разбалловка задач (за исключением сайта кафедры). Период, в течении которого задачи должны были быть решены. Возможно, указать язык программирования, если курс специализирован. Вид составления рейтинга. Чтобы занести эти данные, в интерфейсе должны содержаться элементы, приведенные в табл. 1:
Табл.1 Также должны быть функциональные элементы – кнопки, которые позволяют совершать пользователю следующие действия: Добавить строку в таблицу (на каждую таблицу). Удалить строку из таблицы (на каждую таблицу). Получить отчет. Удобство привнесет наличие меню, которое будет содержать пункты: Сохранить/загрузить курс. Сохранить/загрузить список инспектируемых студентов. Инструкция. Карта пользовательского интерфейса представлена в табл.2
Табл. 2 5. Реализация ПП | ||||||||||||||||||