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

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

РЕФЕРАТ

Количество иллюстраций: 48

Количество приложений: 4

Количество страниц: 82

Количество таблиц: 41

Количество использованных источников: 35

Ключевые слова: САЙТ, EJB, JSF, БАЗА ДАННЫХ, УРОВЕНЬ.

В качестве объекта исследования был выбран сайт учебного процесса. Цель работы - автоматизация взаимодействия преподавателя и студента через сайт, ведение централизованного процесса обработки данных. В результате написания работы методами исследования были перечень технологий, таких как EJB3.0, JMS, JPA, HSQL/SQL, JSF(WebUI), Glassfishv2, NetBeans6.0, Reflection, Subversion SVN, JAAS. В результате исследования обнаружилось, что для работы на бизнес уровне работа с EJB3.0 эффективная и быстрая в разработке, поддерживается как сервером приложений Glassfishv2 так и многими другими J2EE серверами. Взаимодействие между бизнес уровнем и уровнем контроллера и представления, написанного на JSF - не имеет проблем. В то время как взаимодействие двух модулей JSF и GWT имеют проблемы. Возможное использование этих двух технологий возможно при их функциональной независимости друг от друга.

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

Применять этот сайт необходимо в высших учебных заведениях.

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

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

ОГЛАВЛЕНИЕ

• ВВЕДЕНИЕ
• ГЛОССАРИЙ
• 1. ПОСТАНОВКА ЗАДАЧИ
• 2. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
• 3. ПРОЕКТИРОВАНИЕ
• 4. РАЗРАБОТКА
• 4.1 Разработка архитектуры системы
• 4.2 Определение функций, выполняемых программой (Use Case Diagram)
• 4.3 Разработка диаграмм последовательности (Sequence Diagrams)
• 4.4 Разработка графического интерфейса программы
• 4.5 Разработка диаграммы классов(Class Diagram)
• 4.6 Разработка алгоритмов выполнения методов класса (Activity Diagram)
• 4.7 Разработка диаграммы развертывания (Deployment Diagram)
• 4.8 Разработка базы данных
• 4.8.1 Разработка физической модели базы данных
• 4.8.2 Разработка бизнес правил базы данных
• 4.8.3 Описание таблиц БД
• 4.9 Кодирование и отладка
• 5. ТЕСТИРОВАНИЕ
• 6. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ
• ПРОГРАМННОГО ПРОДУКТА
• 6.1 Теоретическое обоснование экономической выгоды от внедрения программного продукта в высших учебных заведениях
• 6.2 Расчет себестоимости и цены программного продукта
• 6.3 Стратегия маркетинга
• 7. ОРГАНИЗАЦИЯ УСЛОВИЙ ПО ОХРАНЕ ТРУДА
• 7.1 Организация рабочего места администратора проекта
• 7.2 Анализ вредных производственных факторов в серверной комнате
• 7.3 Характеристика помещения серверной комнаты
• 7.4 Разработка и формирование мероприятий по уменьшению влияния вредных и опасных факторов
• 7.4.1 Требования к освещенности помещения
• 7.4.2 Ионизирующее и электромагнитное излучения
• 7.4.3 Требования к электробезопасности
• 7.5 Обеспечение техногенной безопасности
• 7.5.1 Анализ возможных чрезвычайных ситуаций
• 7.5.2 Прогнозирование последствий ЧС техногенного характера, вызванных пожаром
• 7.5.2.1 Основные мероприятия по локализации и устранению пожаров
• 7.5.2.2 Вынужденная эвакуация людей из помещения серверной комнаты при пожаре
• 7.5.2.3 Расчет размеров зоны возможных сплошных и отдельных пожаров
• ЗАКЛЮЧЕНИЕ
• БИБЛИОГРАФИЧЕСКИЙ СПИСОК
• ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

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

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

ГЛОССАРИЙ

1) Open source software - открытые программные средства, т.е. такие лицензионные программы, которые вместе с их исходными текстами, не связанны ограничениями на дальнейшую модификацию и распространение с сохранением информации о первичном авторстве и внесённых изменениях.

2) Application Framework - каркас приложения (открытая инфраструктура приложения). Это software framework, который используется, чтобы обеспечивать выполнение стандартной структуры приложения для определенной операционной системы.

3) Software Framework-- каркас программной системы (или подсистемы). Может включать вспомогательные программы, библиотеки кода, язык сценариев и другое ПО, облегчающее разработку и объединение разных компонентов большого программного проекта. Обычно объединение происходит за счет использования единого API.

4) Контроллер - интерпретирует данные, введенные пользователем, и информирует модель и представление о необходимости соответствующей реакции

5) База данных - структурированный организованный набор данных, описывающих характеристики какой-либо физической или виртуальной системы.

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

7) Представление - отвечает за отображение информации.

8) Модель - модель предоставляет данные а также реагирует на запросы ( обычно от контролера), изменяя свое состояние.

9) Контейнер - это структура, позволяющая инкапсулировать в себя объекты разных типов, в основном они построены на основе шаблонов.

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

11) Сущность - тип EJB, компонент J2EE серверной части, который представляет сохраняемые данные, управляемые в базе данных.

12) Локальные бины - объекты, не меняющие своего состояния в процессе исполнения, которые имеют область видимости внутри контейнера

13) Удалённые бины - объекты, не меняющие своего состояния в процессе исполнения, которые имеют область видимости внутри и вне контейнера.

14) Java Message Service (JMS) -- стандарт промежуточного ПО для рассылки сообщений, позволяющий приложениям, выполненным на платформе J2EE, создавать, посылать, получать и читать сообщения. Коммуникация между компонентами, использующими JMS, асинхронна (процедура не дожидается ответа на своё сообщение) и независима от исполнения компонентов.

1. ПОСТАНОВКА ЗАДАЧИ

Данная система необходима для автоматизации учебного процесса. А именно, для:

· создания единой базы работников высшего учебного заведения (преподаватели, лекторы, деканы) и студентов;

· добавления, редактирования, удаления пользователей;

· ведения информации о факультетах, кафедрах, специальностей;

· конфигурирования системы количества корпусов, количества аудиторий в них, их вместимости, под конкретное высшее учебное заведение;

· установления времени начала и окончания пары, перемены между ними;

· общение между преподавателем и студентом в электронной форме;

· ведение успеваемости и посещаемости студентов;

· получение свежих новостей и событий в университете;

· просмотр преподавательского состава, и дополнительной информации о них;

· возможность просмотра расписания на текущий семестр, внесения изменений и добавление нового, посредством excel-документа;

· составление преподавателями и их ассистентами тестов для студентов;

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

Для реализации вышеперечисленных идей, необходимо проект разбить на логические модули. Это необходимо для того, чтобы избавиться от лишних зависимостей в системе. В данном проекте необходимо выбрать архитектуру на основе MVC [6], так как она решает поставленные задачи и широко применяется в WEB-программировании. Таким образом, мы разбивает проект на три логических модуля. Рассмотрим уровень представления. Эта система должна быть доступна как пользователям, так и администратору. Поэтому есть смысл разбить уровень представления на 2 независимые составляющие. Способ автоматического открытия пользователю системы в административной консоли или пользовательского сайта должен определяться на уровне авторизации. Так как для каждой страницы должен быть свой модуль, а уровень представления у нас состоит из двух независимых модулей, то уровень контроллеров у нас тоже разделён на две части. Уровень данных у проекта один, так как контроллеры используют для своей работы одинаковые данные. Но в свою очередь есть смысл разбить уровень данных на два уровня. Первый из них будет работать непосредственно с базой данных, в нём будут находиться только запросы в базу данных. Второй будет их обрабатывать, производить какие-то вычисления, конвертировать в более подходящие структуры данных для удобства использования на уровне представления.



Рисунок 1.1 - Концепции архитектуры приложения

Нашу архитектуру отражает Рисунок 1.1. Давайте теперь рассмотрим отдельные вещи более подробно:

Общие детали проекта:

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

2. На сайте одни и те же страницы должны отображаться по-разному, иметь разную функциональность, в зависимости от роли.

3. Роль пользователя должна выставляться администратором, при его добавлении и/или редактировании.

4. Сокрытие информации присущей конкретной роли должна производиться на уровне презентации.

5. Информация о роли пользователя должна быть присуща в сессии.

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

Административная консоль:

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

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

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

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

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

1. Реализовать авторизацию, аутентификацию пользователей.

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

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

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

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

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

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

8. Страница литературы должна быть идентична по структуре странице тестов.

2. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

Данный проект мог быть реализован с помощью других технологий. Проведём аналогию. Данный проект может быть написан, используя другие альтернативные технологии, рассмотрим их преимущества и недостатки. В качестве альтернативы EJB можно было бы выбрать Spring, если бы наша задача стояла в том, чтобы это приложение могло работать только на одном сервере. Преимущества заключались бы в том, что мы получили бы большую производительность из-за упрощенной архитектуры Spring по отношению к EJB. В данном случае был выбран EJB, чтобы в дальнейшем можно было расширить приложение до кластерного уровня. В качестве альтернативы, использованию JSF, можно было бы выбрать такие технологии как Struts, GW, JSP/Servlets. Struts по сравнению с JSF, имеет преимущества в более удобной настройке компонентов, так как работа верстальщика не пересекается с работой разработчика, чего нет в JSF. GWT имеет встроенные возможности Ajax'a и предоставляет собой такую же архитектуру кодирования как и Swing. JSP/Servlet являются наиболее быстрым в скорости работы и являются базовым функционалом для вышеперечисленных фреймвёрков. В качестве базы данных можно было выбрать PostgreSQL, его возможности являются наряду с Oracle и в то же время является бесплатным для использования. Сайт на данный момент имеет административную консоль. На данном этапе разработки на ней (консоли) можно выполнять работу с данными над пользователями, преподаваемыми предметами, факультетами, кафедрами, специализациями студентов. В дальнейшем необходимо добавить возможность работы с корпусами университета, аудиториями, временем проведения пар, возможность создания расписания. Для данных страниц должен быть использован тот же подход создания, как и для предыдущих. Так как страницы будут предоставлять однотипный интерфейс для конечного пользователя.



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

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

На данном этапе разработки есть компонент на странице добавления/редактирования студента, позволяющий загружать файлы. Выполняют задачу загрузки фотографий пользователей. На данный момент реализация не была осуществлена. Но для неё уже есть базовый функционал в приложении. Разработаны две сущности FileDescriptor и FileData. В сущность UserEntity добавлено поле, которое является в отношении один-ко-одному с сущностью FileDescriptor. Для дальнейшей разработки, необходимо имплементировать сервисы загрузки и редактирования фотографий (как это можно сделать, можно прочесть в [17]), установить фильтры на добавление файлов с расширением JPG, JPEG, GIF, PNG, JPE, JFIF, BMP, DIB, TIF, TIFF, так как они предоставляют собой форматы графических файлов. На загрузку остальных форматов установить запрет с выводом сообщения пользователю. Так же ограничить максимальный объём фотографии до 2Мб. Фотография при отображении на экране должна автоматически принимать одинаково установленные размеры. Например, 150 на 200 пикселей.

Данная реализация JSF - WebUI[12] не имеет возможности работать асинхронно. Переход на другую имплементацию невозможен, из-за специфической организации и различия архитектуры с альтернативными продуктами. Поэтому возможно переопределение имеющихся компонентов на уровне исходного кода WebUI-компонентов. Нужно добавить в необходимые компоненты дополнительный атрибут partialSubmit, который будет сигнализировать компоненту о том, что при изменении данных, на уровне контроллера, автоматически реагировать, не ожидая перезагрузки страницы. Сама реализация Ajax'a должна быть осуществлена через объект XMLHttpRequest[13]. Для реализации потребуется в дескрипторе развёртки объявить ещё один сервлет, который будет обрабатывать данные запросы.

В существующей реализации проекта предусмотрен в дескрипторе развёртки фильтр, в котором можно задать правила, по которым будет осуществляться навигация по сайту. При авторизации каждый из пользователей обладает своей ролью. Их всего может быть четыре: Guest, Administrator, Student, Lector. При дальнейшей разработке необходимо в методе doFilter класса имплементирующего интерфейс javax.servlet.Filter[14], в нашем случае это SecurityFilter, имплементировать логику доступа к каждой из страницы сайта. При захождении по прямому URL-адресу[15], SecurityFilter должен пропускать только тех пользователей, которые имеют на это право, остальных автоматически отправлять на страницу с 403 ошибкой [16]. На все страницы административной консоли может попадать только администратор. Гость может видеть только информацию об университете, и не имеет своих личных страниц на сайте. У студентов и преподавателей есть свои страницы, на которые могут попасть только они. Причём, студент не должен обладать правом просмотра данных другого студента, также как и преподаватель не может посмотреть успеваемость студентов не по его предметам или студентов, у которых он не читает лекций (либо ведёт практику). В дальнейшем предусматривается возможность введения новой роли, с помощью которой можно будет просматривать успеваемость и посещение занятий всех студентов. Эта возможность должна быть предоставлена кураторам, сотрудникам деканата.

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

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

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

На сайте должна быть предоставлена возможность студенту выбирать возможность, на какие типы SMS-рассылок он может подписаться. Это может быть: изменение в расписании, уведомление за определённое время до контрольной работы, и другие виды сообщений.

Главная страница сайта должна предоставлять возможность CMS[18]. Для этого также должна быть добавлена для этого соответствующая роль, позволяющая это делать. Что можно будет редактировать. Должна быть возможность изменения рисунка, фона страницы, содержимого страницы. Если текст пишется в стиле URL-адреса, чтобы предоставлялась возможность захода на этот сайт посредством единого нажатия левой клавиши мыши на нём.

Очень актуальными сейчас являются WEB сервисы[19]. В данном приложении их можно было бы использовать с целью проверки наличия студента в университете. Либо узнавать количество студентов, окончивших с красным дипломом. Некоторые модули, которые могут быть написаны на других технологиях, можно было бы состыковать посредством именно WEB сервисов. Также они могут быть полезны при возможности интерактивного обмена между двумя и более подобными сайтами, установленными в разных высших учебных заведениях. Например, при переходе студента из одного университета в другой с передачей всех его личных данных.

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

3. ПРОЕКТИРОВАНИЕ

Вследствие отсутствия финансирования проекта, при выборе инструментальных средств, предпочтение отдавалось условно бесплатным проектам. Лидирующее место на рынке таких продуктов в настоящее время занимает компания Sun Microsystems и для разработки все её продукты являются бесплатными. Основным языком программирования WEB-приложений является Java. Система была реализована по архитектуре "модель-контроллер-представление".

Рисунок 3.1 - Система по архитектуре "модель-контроллер-представление"

Данная архитектура полезна в приложениях, где необходимо разделить логику на 3 отдельных независимых модуля. Широко применяется в WEB-приложениях. Как известно, в MVC-приложениях используются модели двух типов: активные и пассивные. Первые сами являются инициаторами обновления отображаемых данных, а, следовательно, связаны с представлением. Зато последние не предпринимают самостоятельных действий, а лишь ожидают изменений от контроллера.

На основании изложенных фактов, мною были выбраны:

· средой разработки - NetBeans 6.0, так как имеет способность работы с новыми технологиями, предоставление возможности автоматической генерации кода, автоматическое дополнение необходимых библиотек для выбранной технологии. При сравнении с аналогичными бесплатными для разработки средами разработки, такими как Eclipse, JDeveloper имеет преимущества. Eclipse трудоёмкий в настройках, JDeveloper имеет хорошие показатели при работе с продуктами компании Oracle, в других ситуациях неудобен в использовании.

· в качестве WEB-сервера - Glassfish v2, так как имеет возможность работы с EJB, сервер является кластеризуемым, надёжным. Предоставляет удобную графическую административную консоль. Для использования в данном сайте не требует дополнительных настроек. При возникновении ошибок детально описывает проблему в логах. По сравнению с такими WEB-серверами как BEAWebLogic, IBM WebSphere работает значительно быстрее, не упоминая о том, что они являются не просто платными, а очень дорогими. Альтернативой использования может быть JBoss или Sun Application Server 9.

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

· в качестве реализации уровня контроллера и представления -JSF, потому что предоставляет возможность быстрой разработки, предоставляет использование своих компонентов. Архитектура технологии предоставляет гибкость использования. Имеет недостатки в написании собственных компонентов, переопределении имеющихся. Большим недостатком является то, что работа верстальщика и разработчика часто пересекается по причине генерации HTML и JavaScript кода внутри Java-кода.

· в качестве имплементации JSF - WebUI, так как в среде разработки NetBeans предоставляется удобная палитра для разработки jsp-страниц с автоматической генерацией кода.

· в качестве используемой СУБД - MySQL 5.0, так как является продуктом OpenSource. Имеет удобный графический интерфейс при работе с базой данных.

4. РАЗРАБОТКА

4.1 Разработка архитектуры системы

Данное приложение является клиент-серверным, с тонким клиентом и имеет "многозвенная клиент-серверная" архитектура.

Рисунок 4.1 - Архитектура приложения

Состоит из 2-х модулей, имеет 4 логических уровня: DAO уровень, уровень сервисов, уровень контроллеров, уровень представления. DAO уровень работает непосредственно с базой данных с помощью EJB QL запросов, и являются локальными бинами в EJB-контейнере. Уровень сервисов вызывает методы из DAO уровня, выполняя соответствующие преобразования, если необходимо. Уровень сервисов является открытым для других модулей программы. Контроллеры взаимодействуют именно с этим уровнем. В контроллерах обрабатывается информация, пришедшая из уровня представления, а также предоставляется необходимая информация для неё из EJB-модуля. Уровень представления только отображает информацию, без её модификации.

4.2 Определение функций, выполняемых программой (Use Case Diagram)

автоматизация сайт интерфейс программный

Рисунок 4.2 - Функции студента

Рисунок 4.3 - Функции администратора системы

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

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

4.3 Разработка диаграмм последовательности (Sequence Diagrams)

Рисунок 4.4 - Диаграмма последовательности авторизации

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

Рисунок 4.5 - Диаграмма последовательности добавления/редактирования студентов

На данной диаграмме рассмотрен процесс работы добавления и редактирования студента. После успешной аутентификации администратором, сайт открывает страницу Admin.jsp на которой можно выбрать нужного для редактирования пользователя, либо добавить нового. При выборе той или иной функции сайт открывает страницу AddEditUser.jsp. При входе на данную страницу администратору предоставляются поля ввода данных пользователя. После нажатия на кнопку Cancel - произойдёт переход обратно на главную страницу административной консоли, при нажатии Save/Edit(значение кнопки изменяется в зависимости от способа захода на страницу) выполняется проверка на корректность введённых данных. В случае корректного заполнения необходимых полей, вносятся изменённые данные в базу данных, и происходит переход на главную страницу консоли. При потере авторизации сайт возвращается на страницу авторизации.

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

Рисунок 4.6 - Диаграмма последовательности главной страницы административной консоли

4.4 Разработка графического интерфейса программы

Рисунок 4.7 - Страница авторизации пользователей

Таким образом, выглядит страница авторизации. Имеется 2 поле ввода, для имени авторизации и пароля, кнопки авторизации и кнопки, позволяющей войти на сайт, как гостю.

Рисунок 4.8 - Главная страница административной консоли

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

Рисунок 4.9 - Страница редактирования/добавления пользователей

Данная страница предоставляет собой форму, для добавления, редактирования данных пользователя. Содержаться такие поля как ФИО, адрес, номер телефона, почтовый электронный адрес, день рождения, тип пользователя, фотография (будет реализована в дальнейшем), имя авторизации и пароль пользователя. Поля, которые являются обязательными, помечены звёздочками. Есть кнопка сохранения/редактирования и отмены, с возвратом на главную страницу консоли.



Рисунок 4.10 - Интерфейс однотипных страниц в административной консоли

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

Рисунок 4.11 - Страница для редактирования корпусов ВУЗа и установление времени для каждой пары



Рисунок 4.12 - Редактирование предметов и выделение преподавателю прав на их проведение

Рисунок 4.13 - Страница, позволяющая импортировать данные о расписании из Excel файла, и предоставляющая возможность привязки преподавателям к предметам



Рисунок 4.14 - Страница для задания специфических значений каждому из корпусов университета

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

Рисунок 4.15 - Страница, которая показывается пользователю в случае нехватки прав доступа к ресурсу

Рисунок 4.16 - Страница для изменения паролей

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

Рисунок 4.17 - Главная страница портала

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

Рисунок 4.18 - Страница расписания занятий текущего семестра

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

Рисунок 4.19 - Страница пришедших напоминаний

Данная страница предоставляет возможность просмотра важных напоминаний. Первая колонка слева содержит в себе напоминания, под ней находится кнопка "Прочитати > " открывающая содержание напоминания, и отображается в центральной колонке. Особо важные напоминания можно сохранять в правой колонке. Данная страница находится на стадии разработки.

Рисунок 4.20 - Страница успеваемости и посещаемости студента

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

Рисунок 4.21 - Страница отправки писем

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

Рисунок 4.22 - Страница пришедших писем

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

Рисунок 4.23 - Страница оценивания и отмечания успевания студентов

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

Рисунок 4.24 - Страница всех преподавателей университета

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

Рисунок 4.25 - Литература для просмотра и скачивания пользователям портала

Рисунок 4.26 - Страница позволяющая добавлять и редактировать существующие тесты

По представленным выше изображениям, как должна выглядеть система, есть смысл составить по ним диаграммы классов, которые помогут это реализовать.

4.5 Разработка диаграммы классов(Class Diagram)

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

Рисунок 4.27 - Диаграмма классов, реализующих функциональность сущности, пользователя и его наследников

На диаграмме 4.28 представлено взаимосвязь сущностей, которые отвечают за проведение занятия (Lesson). Занятие может быть либо лекцией (Lection), практикой (Seminar) либо экзаменом (Examination). Сущность "Занятие" наследует все свойства, которые находятся в сущности Schedule, которая в свою очередь содержит информацию о том: в какой аудитории какого корпуса будет проведено занятие; время и день проведения; группа, которая будет на этом занятии; преподаватель, который будет проводить это занятие; семестр проведения этого занятия.

Рисунок 4.28 - Диаграмма классов, реализующих функциональность сущности, урока и его зависимостей

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

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

Рисунок 4.30 - Диаграмма зависимости классов, реализующих функциональность сущности, факультета с сущностью кафедра

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



Рисунок 4.31 - Диаграмма зависимости классов, реализующих функциональность сущности, группы студентов с сущностью читаемый предмет

Данная диаграмма представляет собой отношение проводимых предметов определённой группе студентов.

Рисунок 4.32 - Диаграмма классов, реализующих функциональность сущности, пользователя с зависимостями

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

Рисунок 4.33 - Диаграмма класса, реализующего функциональность сущности, теста и его зависимости

Сущность тест ("TestEntity") устроен таким образом, что содержит связи, на совокупности тестов ("Quiz"). Это говорит о том, что один и тот же вопрос может конфигурировать больше, чем в одном тесте. Также тест, содержит в себе сущности вопросов ("QuiestionEntity") и ответов ("AnswerEntity"). Связи сущностей вопросов и ответов между собой никак не связаны, а поэтому при составлении теста, вопросы, которых может быть несколько должны иметь одинаковые варианты ответов и тот же самый правильный ответ. Это необходимо для того, чтобы была возможность формулировки одинакового вопроса несколькими способами.

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

4.6 Разработка алгоритмов выполнения методов класса (Activity Diagram)

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

Рисунок 4.34 - Диаграмма отображения страницы



Рисунок 4.35 - Диаграмма обработки действий пользователя

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

Рисунок 4.36 - Диаграмма обработки нажатия кнопки "Добавити"

После того, как пользователь нажимает на кнопке добавить запись, происходит запись этого действия. Когда происходит перерисовка страницы, то отображается дополнительная форма для ввода данных.

Рисунок 4.37 - Диаграмма отображения и заполнения дополнительной формы

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

Рисунок 4.38 - Диаграмма логики работы удаления записи из таблицы

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

Рисунок 4.39 - Диаграмма классов логики работы нажатия кнопки "Сохранить/Редактировать"

Данная диаграмма предоставляет собой логику работы нажатия кнопки "Сохранить/Редактировать". Сначала сохраняется предыдущее действие. Получаем сущность и проверяем, есть ли она. Если нет, тогда берём значения компонентов, по их именам. Проверяем полученные значения на наличие, если нет хотя бы одного значения, получаем ошибку, в противном случае, получаем данные, для сохранения полученных значений. Вызываем методы, которые в результате получают новую сущность, если в процессе создания не произошло ошибок, то полученная сущность сохраняется или редактируется, если она уже существовала. Диаграмма развёртывания поможет нам понять, как взаимодействуют между собой модули программы, для их совместной работы.

4.7 Разработка диаграммы развертывания (Deployment Diagram)

Рисунок 4.40 - Диаграмма развертывания системы

На данной диаграмме можно увидеть, что приложение состоит из трёх узлов. Клиент, обращаясь через WEB-браузер, взаимодействует с GlassFish сервером, который в себе разворачивает EJB контейнер, и взаимодействует с сервером базой данных MySQL для выборки данных.

4.8 Разработка базы данных

Анализ технического задания на разработку информационно-справочной системы, требований к системе обеспечения информационной безопасности и политики ИБ показал, что в базе данных (БД) целесообразно хранить:

1) информацию о пользователях (тип пользователя, имя, день рождения, адрес, номер телефона, логин/пароль в систему, электронный адрес, описание, и если это студент - группу);

2) информацию о кафедрах, специальностях, факультетах;

3) книги, фотографии, другие файлы;

4) тесты (вопросы, ответы, вопросники);

5) информацию о расписании (даты сессии для каждой кафедры, время, место проведения пар и кем они должны быть проведены);

6) информацию о предметах (кто их имеет право преподавать), информацию об университете (о корпусах, сколько в них этажей, какие есть аудитории, сколько их, какой они каждая вместительности).

Нормализация базы данных

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

Первая нормальная форма:

· запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию);

· запрещает множественные столбцы (содержащие значения типа списка и т.п.);

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

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

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

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

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

Пятая нормальная форма. Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальной форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается. Из вышеуказанной теоретической сноски, можно сказать, что в данном приложении используется четвёртая нормальная форма, что мы сейчас сможем увидеть из таблиц баз данных.

4.8.1 Разработка физической модели базы данных

Рисунок 4.41 - Физическая структура реализации модели Расписание и его связи



Рисунок 4.42 - Физическая структура реализации модели Тест

Рисунок 4.43 - Физическая структура реализации модели Пользователь и его связи

4.8.2 Разработка бизнес правил базы данных

1) Все таблицы имеют первичный ключ BIGINT(20) с автоматическим инкрементированием при добавлении новой записи в таблицу.

2) Таблица UserEntity является общей таблицей для записей 4 типов объектов: студента, администратора, преподавателя и гостя. Различие между разными типами сущностей происходит по дополнительному столбцу discriminator.

3) Таблица Lesson подобна по реализации таблице UserEntity, совмещает в себе 2 сущности: лекционное занятие и практическое.

4) Таблицы BirthDate, Address, UserEmail, Credential, TelephoneNumber связаны только с сущностью UserEntity, и поэтому при удалении сущности пользователя автоматически удаляются записи в вышеперечисленных таблицах, для предотвращения "висящих" данных.

4.8.3 Описание таблиц БД

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



4.9 Кодирование и отладка

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

5. ТЕСТИРОВАНИЕ

Виды тестирования:

Unit-тестирование (модульное тестирование) -- данный вид подразумевает тестирование отдельных модулей приложения. Для получения максимального результата тестирование проводится одновременно с разработкой модулей.