диплом. Руководство пользователя 50
 Скачать 3.32 Mb.
|
|
2.3.3 Сравнительная оценка сервисов. Изучив приведённые системы тестирования и проверки знаний пользователей, выделены следующие общие недостатки рассмотренных сервисов: нет гибких механизмов разграничения доступа к данным; недостаточная функциональность; неудобный интерфейс; сложность в эксплуатации и использовании; избыточность информации; отсутствие масштабирования. Изучив основные плюсы и минусы систем-тестирования пользователей принято решение о проектировании и реализации программной поддержки компетенций специалистов по иностранному языку, которая будет включать следующие функции присущие её аналогам: учёт пользовательской базы; учёт базы отделов и департаментов компании; формирование поиска по заданным ключам, атрибутам; наличие возможность управление тестированием; возможность прохождения тестирования в режиме реального времени; наличие журнала отчётов по пройденному тестированию. Также при реализации системы требуется придерживаться следующим принципам: Доступность. Работа системы не должна зависеть от программного обеспечения или конфигурации компьютера пользователя. Расширяемость. Что значит возможности добавления в систему новых модулей и тематического контента, должно быть простым и не должно влиять на работу системы в целом. Информативность. Предоставляемая системой информация должна быть структурирована и представлена пользователю в удобном для восприятия виде. Надёжность. Хранимая и передаваемая по каналам связи информация, должна обладать определённым уровнем защиты. Интерактивность. Анализируя действия пользователя, система должна выдавать рекомендации и персонализировать интерфейс исходя из логических выводов, основанных на базе знаний и правил. Экономичность. Стоимость программного продукта, ввод в эксплуатацию и дальнейшее использование значительно ниже его аналогов. Система будет разрабатываться как веб-приложение, позволяющая производить проверку знаний пользователей по иностранным языкам через интернет доступ. 2.4 Функциональная методология процесса оценки компетенций Исходя из описания основных бизнес процессов, анализа автоматизации процесса оценки компетенций и сравнительного анализа систем аналогов, требуется составить следующую функциональную модель, представленную на рисунке 2.7.  Рисунок 2.7 – Функциональная модель процесса организации проверки компетенций сотрудников Входной поток включает в себя заявки компании и материальные средства, необходимые для организации проверки компетентностей сотрудников. После выполнения процесса организации проверки компетентностей сотрудников на выходе получаем отчеты, содержащие всю информацию о ходе проведения оценки навыков и умений. Управление процессом проведения оценки знаний контролируется нормативно актами, требованиям к оценке кандидатов, приказами и поручениями вышестоящих органов. Механизмами, которые непосредственно выполняют эту работу, являются руководитель, экзаменатор и сотрудники компании. Далее, на рисунке 2.8, показана декомпозиция контекстной диаграммы для процесса проверки компетенций знаний сотрудников по иностранному языку.  Рисунок 2.8 – Декомпозиция контекстной диаграммы Декомпозиция контекстной диаграммы, которая включает пять основных функциональных процесса в проверке компетенций знаний сотрудников: выявить требования к оценке компетенций; утвердить цели оценки; определить содержание тестирующей программы; провести оценку; оценить эффективность оценки. Первым этапом в организации процесса оценки компетенций сотрудников компании по иностранному языку является выявлении потребности в оценке сотрудников. Для дальнейшей организации необходимо утвердить цели оценок для получения определенных результатов. Затем необходимо определиться с содержанием форм и методов проверки и оценки. Далее следует этап проведения оценки сотрудников по иностранным языкам и оценка эффективности оценки. 2.5 Анализ принципов разрабатываемого веб-приложения по проверке компетенций сотрудников Разрабатываемое веб-приложение по оценке навыков и компетенций специалистов по иностранному языку использует клиент-серверную архитектуру, в котором клиентом выступает браузер, а сервером – веб-сервер. Логика веб-приложения распределена между сервером и клиентом, хранение данных осуществляется, преимущественно, на сервере, обмен информацией происходит по сети. Одним из преимуществ такого подхода является тот факт, что клиенты не зависят от конкретной операционной системы пользователя, поэтому веб-приложение является межплатформенными сервисом. Для более детального рассмотрения взаимодействия компонентов системы трёхуровневой структуры данных приведена диаграмма последовательности работы приложения, показанная на рисунке 2.9.  Рисунок 2.9 – Диаграмма последовательности компонентов Разрабатываемая система состоит как минимум из трёх основных компонентов: клиентская часть, серверная часть и база данных. 1 Клиентская часть веб-приложения – это графический интерфейс. Это то, что отображается на веб-странице. Графический интерфейс отображается в браузере. Пользователь взаимодействует с веб-приложением именно через браузер, переходя по ссылкам и нажимая на кнопки. 2 Серверная часть веб-приложения – это программа или скрипт на сервере, обрабатывающая запросы пользователя (точнее, запросы браузера). При каждом переходе пользователя по ссылке, браузер отправляет запрос к серверу. Сервер обрабатывает этот запрос, вызывая некоторый скрипт, который формирует веб-страничку, описанную языком HTML, и отсылает клиенту по сети. Браузер тут же отображает полученный результат в виде очередной веб-страницы. 3 База данных (БД, или система управления базами данных, СУБД) – программное обеспечение на сервере, занимающееся хранением данных и их выдачей в нужный момент. База данных располагается на сервере. Серверная часть веб-приложения обращается к базе данных, извлекая данные, которые необходимы для формирования страницы, запрошенной пользователем [8]. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ПРОГРАММНОЙ ПОДДЕРЖКИ ОЦЕНКИ И ПРОВЕРКИ ЗНАНИЙ СОТРУДНИКОВ ПО ИНОСТРАННОМУ ЯЗЫКУ 3.1 Постановка задачи Целью данной дипломного проекта является разработка программной поддержки компетенций специалистов по иностранному языку, которая будет сочетать в себе функции контроля и учёта, управления данными о пользователях системы, базе тестов и результатов их прохождения. Предполагается, что система будет ориентирована для ИТ-компании, которой необходима систематическая проверка знаний сотрудников по иностранным языкам, ориентируясь на предполагаемые проекты или условия отдела, в котором работает сотрудник. Система должна быть реализована в виде веб-приложения, с использованием языков программирования PHP и Javascript, СУБД Mysql, а в качестве программной платформы использоваться Yii framework. Система должна иметь удобный и функциональный интерфейс. Дизайн требуется выполнить в спокойных тонах не напрягающий глаза пользователей. Расположение кнопок на форме максимально удобно для работы. При разработке дизайна учитывался ряд общепринятых правил: гармоничное сочетание цветов, пропорциональность размеров элементов, интуитивно понятный интерфейс. Система должна обладать простотой в использовании и обслуживании, а также иметь относительно недорогую стоимость создания, внедрения и обслуживания продукта. В рамках разработки программного средства, должные быть реализованы следующие задачи: регистрация и авторизация пользователей; управление правами пользователей; добавление вопросов; создание тестов (возможно, с упрощённым набором свойств); прохождение теста (возможно, в упрощённом виде – без учёта разных настроек и нюансов); отображение подробного результата теста для сотрудника; отображение статистики по каждому тесту/слушателю. Разрабатываемое приложение должно удовлетворять требованиям расширяемости (добавление новых типов теста, большего числа вопросов и т.д.) и универсальности. Минимальный комплекс технических средств: один сервер, который предоставляет доступ к интерфейсу системы и функциональному блоку. Минимальные системные требования: веб-сервер Apache; языки программированияPHP, Javascript; СУБДMySQL; Framework Yii; процессор: 3000+ МГц; оперативная память: 4гб+; свободное место на HDD: 100гб+; браузер: Internet Explorer, Google Chrome, Firefox, Safari, Opera последних версий; доступ в сеть интернет для каждого компьютера. 3.2 Проектирование логической модели данных Логическая схема – модель базы данных, выраженная в понятиях модели данных. Этим отличается от концептуальной модели, описывающей семантику предметной области без указания технологии (конкретных методов реализации), и от физической модели, которая описывает конкретные физические механизмы, применяемые для хранения данных в накопителях. Логическая модель данных является визуальным графическим представлением структур данных, их атрибутов и связей. Логическая модель представляет данные таким образом, чтобы они легко воспринимались бизнес-пользователями. Проектирование логической модели должно быть свободно от требований платформы и языка реализации или способа дальнейшего использования данных. При разработке используются требования к данным и результаты анализа для формирования логической модели данных. Логическую модель приводят к третьей нормальной форме, и проверяет ее на соответствие модели процессов. Основными компонентами логической модели являются: сущности; атрибуты сущности; связи между сущностями. Сущность моделирует структуру однотипных информационных объектов (документов, хранилищ данных, таблиц базы данных). Атрибут – любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Связь – это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя [9]. Исходя из анализа предметной области, из выделенных форматов входных-выходных данных, а также на основе описанных функциональных блоков составлена следующая логическая модель данных для программного комплекса распределения продукции, которая показана на рисунке 3.1.  Рисунок 3.1 – Логическая модель базы данных Как видно из архитектуры базы данных и её описания, она находится в 3-й нормальной форме. Далее описано доказательство приведения БД к 3-й нормальной форме. Таблицы соответствуют 1-ой нормальной форме, т.к. все строки таблицы различны и не являются списками. Исходя из этого, следует вывод что БД соответствует 1-ой нормальной форме. Также таблицы имеют уникальный id – это означает, что БД также находится и во второй нормальной форме. И в заключение, так как данное отношение таблиц находится во второй нормальной форме, каждый не ключевой атрибут находится в не транзитивной зависимости от первичного ключа, а также отсутствует дублирование данных по всей базе данных, то следует сделать вывод что данная архитектура БД находится в 3-й нормальной форме. Далее приведено описание сущностей разработанной логической модели данных для программного комплекса: сущность «пользователи»: данная сущность хранит информацию о зарегистрировавшихся пользователей системе, а также их персональных данных; сущность «типы пользователя»: в данной сущности содержится информация о типе пользователя; сущность «отделы компании»: сущность содержит информацию об отделах и департаментах компании, в которую интегрируется система; сущность «языки отделов»: в текущей сущности хранится информации о принадлежности вида языка, который необходимо знать при работе в выбранном департаменте или отделе компании; сущность «язык»: сущность содержит названия языков, которыми должны владеть сотрудники компании; сущность «тест»: в данной сущности выводится информация о названии теста, а также его описания; сущность «вопросы»: сущность включает в себя информации о вопросах тестирования; сущность «тип вопроса»: текущая сущность содержит в себе данные о типах вопросов; сущность «ответы»: сущность хранит в себе информацию по ответам на выбранные вопросы; сущность «результат теста»: сущность содержит данные о пройденном тестировании выбранного пользователя. 3.3 Диаграммы в нотации языка UML UML – язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода [10]. 3.3.1 Диаграммы вариантов использования. Сценарий использования, вариант использования, прецедент использования (англ. use case) – в разработке программного обеспечения и системном проектировании это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Система может отвечать на внешние запросы Актёра (англ. actor) может сама выступать инициатором взаимодействия. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем». Методика сценариев использования применяется для выявления требований к поведению системы, известных также как пользовательские и функциональные требования. В качестве актёров или, можно сказать, сущностей выступают два вида пользователей: администратор; экзаменатор; пользователь. Для того чтобы войти в систему и получить права доступа, требуется ввести персональные данные и авторизоваться в систему. Если регистрируется пользователь, то по умолчанию он сразу получает права доступа к прохождению тестирования, если же входит администратор или экзаменатор, то вначале ему требуется зарегистрироваться, получить доступ, после чего ему будут доступны все функции присущие его роли. Диаграмма вариантов использования для авторизации пользователя представлена на рисунке 3.2.  Рисунок 3.2 – Диаграмма вариантов использования для незарегистрированного пользователя Далее будет рассмотрена диаграмма вариантов использования для администратора, представленную на рисунке 3.3.  Рисунок 3.3 – Диаграмма варианта использования при роли «Администратор» Данному виду пользователя доступны все функции по управлению правами доступа к системе, уже зарегистрированных пользователей, непосредственно добавлять новых пользователей. Администратор имеет доступ к управлению отделами компании. Также ему доступны функции по управлению тестированием, предоставлению персонального доступа к его прохождению, а также просмотру результатов тестирования пользователей. Диаграмма вариантов использования для экзаменатора представлена на рисунке 3.4. В данной диаграмме представлены действия, которые доступны данному пользователю. Экзаменатор может составлять вопросы, структурируя их по определённым темам либо группам. Создаёт тесты, устанавливает правила сдачи, указывает параметры прохождения и описание для пользователей, которые будут его проходить.  Рисунок 3.4 – Диаграмма варианта использования при роли «Экзаменатор» И последний актёр в системе – это пользователь. Данный тип пользователя может зайти в личный кабинет, просмотреть журнал прохождения тестирования и просмотр результатов. Следующая функция – это непосредственно прохождение тестирования. Он выбирает доступный ему тест, знакомится с правилами прохождения и начинает его проходить. По истечению теста, он получает балл, а также статус сдал или не сдал, после чего вся информация заносится в журнал, который доступен тренеру или администратору для просмотра. Схема вариантов использования для данного типа пользователя показана на рисунке 3.5.  Рисунок 3.5 – Диаграмма варианта использования при роли «Пользователь» 3.3.2 Диаграммы последовательности. Диаграмма, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл (создание-деятельность-уничтожение) и взаимодействие (отправка запросов и получение ответов). Подобно диаграммам коммуникации, диаграммы последовательности (Sequence Diagrams) отображают поток событий в конкретном сценарии варианта использования, но в них больше внимания уделяется именно времени [11]. Основное назначение приведённой диаграммы состоит в описании жизненного цикла работу между пользователями системы и компонентами системы. Далее приведена диаграмма последовательности для процесса авторизации, которая показана на рисунке 3.6.  Рисунок 3.6 – Диаграмма последовательности для процесса авторизации Приведённая диаграмма описывает процесс авторизации пользователя в автоматизированной системе, показывает весь жизненный цикл между объектами системы. 3.3.3 Диаграмма состояний. Главное предназначение диаграммы состояний (State Machine Diagram) – описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла [11]. Диаграмма состояний представлена на рисунке 3.7. На ней показаны состояния, переходы и ожидания переходов объектов, происходящие во время работы пользователя с автоматизированной системой. На приведённой диаграмме описывается работа по проведению тестирования пользователем системы.  Рисунок 3.7 – Диаграмма состояний работы с прохождением тестирования 3.4 Программная реализация Для того чтобы начать работу с приложением, требуется зайти в phpMyAdmin, после чего требуется создать базу данных с названием «language-test». Далее необходимо открыть Open Server, после чего выбрать командную консоль. После того как открылась командная консоль, требуется заполнить базу данных, произведя миграции из исходного проекта. Введя команду php artisan migrate, база данных заполняется таблицами, сохранёнными в корневой папке проекта. Результат выполнения данной команды представлен на рисунке 3.8. После того как были созданы таблицы в базе данных, требуется заполнить их данными, для чего требуется ввести в командной строке команду php artisan db:seed, после чего таблицы заполняются исходными данными. Результат выполнения данной команды представлен на рисунке 3.9. Далее требуется добавить домен в настройках сборки Open Server. Для этого необходимо перейти в раздел Настройки->Домены, выбрать папку исходного проекта и нажать кнопку «Добавить». После чего пользователь выбирает добавленный домен и открывает его, после чего открывается рабочее окно приложения.  Рисунок 3.8 – Результат выполнения миграций  Рисунок 3.9 – Результат выполнения заполнения данными При первом входе происходит обращение к файлу Index.php, который является входной точкой в приложение Yii. Далее вызывается файл web.php, в котором находятся маршрутизаторы, обрабатывающие запросы пользователя. Первым делом система обрабатывает запросы пользователя, которые передаются через запросы GET или POST. Далее представлен список маршрутизаторов разработанного приложения, показанный на рисунке 3.10. Пользователь выбирает действие, система сравнивает данное действие с маршрутом, который прописан в файле web.php, после чего смотрит какой контроллер и метод контроллера вызывается в данном маршруте. Все контроллеры находятся в папке app\Http\Controllers.  Рисунок 3.10 – Маршрутизаторы приложения Далее приведён пример маршрута для выборки данных по выбранным пользователям системы, вызванных через админпанель: Route::get('/admin/users/', 'AdminController@users')->name('admin-users'); На сервер посылается GET запрос на выборку данных, после чего управление передаётся контроллеру AdminController. В текущем маршруте пользователь передаёт запрос на выборку всех пользователей системы при помощи метода Users. Контроллеры находятся в каталоге app\Http\Controllers. Они служат для того чтобы управлять данными, обрабатывать их и передавать пользователю. Диаграмма классов контроллеров представлена в приложении А. Далее представлена программная реализация клаcса Test.Controllers.Объявление пространства имён: namespace App\Http\Controllers; Подключение сторонних файлов: use App\Models\Question; use App\Models\Test; use App\Models\TestResult; use Illuminate\Http\Request; use Illuminate\Support\Facades\Auth; Объявление класса: class TestController extends Controller { Метод получение данных по выбранному тесту: public function index() { $test = Test::all(); return view('test.index')->with(['tests' => $test]); } Метод запуска тестирования: public function start($id) { $result = new TestResult(); $result->user_id = Auth::id(); $result->test_id = $id; $result->success_count = 0; $result->fail_count = 0; $result->save(); $question = Question::query()->where('test_id', $id)->first(); $type = $question->type->id; $view = "question.view-$type"; return view($view)->with(['result'=>$result, 'question' => $question]); } Метод вывода списка ответов: public function answer(Request $request) { $data = $request->all(); $result = TestResult::query()->findOrFail($data['result']); $question = Question::query()->findOrFail($data['question']); $isCorrect = null; if ($question->type_id == 1) { $isCorrect = $question->answers->where('id', $data['answer'])->where('is_correct',1)->all(); } if ($question->type_id == 2) { $isCorrect = true; } if ($question->type_id == 3) { if($data['answer'] == $question->value) { $isCorrect = true; } } if ($question->type_id == 4) { if($data['answer'] == $question->value) { $isCorrect = true; } } if($isCorrect) { $result->success_count = $request->success_count + 1; $result->save(); } else { $result->fail_count = $request->fail_count + 1; $result->save(); } $nextQuestion = Question::query()->where('id',$question->id + 1)->where('test_id', $question->test_id)->first(); if ($nextQuestion) { $type = $nextQuestion->type->id; $view = "question.view-$type"; return view($view)->with(['result'=>$result, 'question' => $nextQuestion]); } return view('success')->with(['result'=>$result]); } } Далее контроллер обращается в модель, которая служит для доступа к базе данных MySQL и обработкой получаемых данных. Файлы моделей располагаются в каталоге app\Models. Модели служат в качестве классов обработки запросов на получение данных, редактирование, обновление или удаление. Структура файлов моделей представлена в приложении А. В качестве примера реализации взята модель User. Метод получения выбранного типа: public function userType(){ return $this->hasOne(UserType::class,'id','user_type_id'); } Выборка из базы по выбранному департаменту: public function department(){ return $this->hasOne(Department::class,'id','department_id'); } Метод получения результатов тестирования пользователя: public function results() { return $this->hasMany(\App\Models\TestResult::class,'user_id', 'id'); } После того как данные получены, они передаются в контроллер, который в свою очередь вызывает в представление, файлы которого находятся в папке resources\views. Представленияимеетв себеhtmlразметку, а также метки php-кода, в которые подставляется данные из массива данных переданных контроллером, после чего данные выводятся пользователю. Далее представлен фрагмент html-кода представления test.view. Подключение шаблона: @extends('layouts.admin') @section('content') <divclass="container"> Форма для отправки данных: Кнопка поиска данных: form> Вывод заголовка третьего уровня: |