Королев Лабораторая работа применение современных опен-соурце
.pdf
|
disciplines |
|||
|
|
|
||
disc_id |
integer |
|||
disc_name |
character varying(50) |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
lections
lec_id |
integer |
<pk> |
discipline_id |
integer |
<fk> |
lec_theme |
character varying(50) |
|
lec_date |
date |
|
|
|
|
|
|
|
|
seminars |
|
|
|
|
sem_id |
integer |
<pk> |
discipline_id |
integer |
<fk> |
sem_theme |
character varying(50) |
|
sem_date |
date |
|
|
|
|
Рис. 4.3. Физическая модель данных для хранения информации по дисциплинам
Таблица disciplines является родительской по отношению к lections и seminars и связана с ними отношениями «один ко
многим», означающими, что одной дисциплине могут соответствовать несколько лекций и несколько семинаров.
Отношения реализованы при помощи внешних ключей discipline_id.
Теоретически, для дисциплины могут также существовать и лабораторные работы, но мы умышленно не станем выделять их в отдельную группу, так как анкеты по ним, с точки зрения авторов, идентичны анкетам по семинарам.
Кажется целесообразным разбить названия лекций и семинаров и даты их проведения на разные множества со взаимосвязью «один ко многим», чтобы для каждого учебного года, где даты проведения, естественно, отличаются от других лет, не менять названия соответствующих занятий. Но авторы пособия предлагают не делать этого в силу того, что, по их мнению, вероятность изменения тематики занятий в каждом новом учебном году достаточно высокая из-за модернизации рабочих программ преподавателем или из-за изменения учебных планов направлений подготовки. Следовательно, данные в столбце с названием занятия по всей таблице будут разными и возможность оптимизации путем разбиения таблицы на две отпадает.
Для удобства использования в перечисленных выше таблицах пусть первичный ключ имеет свойство автоинкремента
31
своих значений, т.е. при добавлении каждой новой записи значение в поле user_id записывается как инкремент к значению предыдущей записи.
Таблицы БД, созданные по двум вышеописанным моделям, заполняются до начала рабочего функционирования системы. Для хранения регистрационных данных таблицы заполняются по спискам групп студентов за определенный год, официально присутствующих в деканате. Для хранения сведений о дисциплинах, по которым проводится анкетирование, таблицы заполняются по данным из рабочего учебного плана кафедры, из расписания занятий на конкретный семестр и из рабочих программ дисциплин.
Физическая модель данных для хранения анкетной информации
На рис. 4.4 показана физическая модель данных для хранения в БД информации по итогам анкетирования студентов.
Анкетные данные хранятся в двух таблицах – lections_ankets и seminar_ankets соответственно. Поля для хранения анкетной информации полностью соответствуют анкетным вопросам, приведенным в разделе по созданию пользовательского интерфейса. Таблица lections_ankets является дочерней по отношению к таблицам students и lections и связана с ними отношениями «один ко многим» со стороны родительских таблиц. Это означает, что к одному студенту могут относиться несколько заполненных им анкет по лекциям, и что по одной конкретной лекции (теме) могут также существовать несколько разных анкет (от разных студентов). Отношения «один ко многим» реализуются при помощи внешних ключей st_id и lec_id.
Те же самые правила распространяются и на таблицу seminar_ankets, являющуюся дочерней по отношению к таблицам students и seminars. Для нее отношения «один ко многим»
реализуются при помощи внешних ключей st_id и sem_id. Окончательная модель данных в ERMaster должна
объединить в себе описанные в этом разделе три модели.
32
students
students_id |
integer |
<pk> |
group_id |
integer |
<fk> |
st_family |
character varying(50) |
|
st_first_name |
character varying(50) |
|
st_sec_name |
character varying(50) |
|
st_pk_number character varying(50)
lections
lec_id |
integer |
<pk> |
discipline_id |
integer |
<fk> |
lec_theme |
character varying(50) |
|
lec_date |
date |
|
|
|
|
|
|
|
|
seminars |
|
|
|
|
sem_id |
integer |
<pk> |
discipline_id |
integer |
<fk> |
sem_theme |
character varying(50) |
|
sem_date |
date |
|
|
|
|
lections_ankets
|
|
|
la_id |
integer |
<pk> |
|
|
|
lec_id |
integer |
<fk2> |
|
|
|
students_id |
integer |
<fk1> |
|
|
|
teor_for_pract int |
|
|
|
|
|
structure |
int |
|
|
|
|
interaction |
int |
|
|
|
|
interesting |
int |
|
|
|
|
adoption |
int |
|
|
|
|
inf_before |
int |
|
|
|
|
|
||
|
|
|
inf_after |
int |
|
|
|
|
activity |
int |
|
|
|
|
addition |
text |
|
|
|
|
comments |
text |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
seminar_ankets |
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
sa_id |
integer |
<pk> |
|
|
|
st_id |
integer |
|
|
|
|
sem_id |
integer |
<fk2> |
|
|
|
|||
|
|
|
students_id |
integer |
<fk1> |
|
|
|
understanding |
int |
|
|
|
|
expectations |
int |
|
|
|
|
skill_for_work |
int |
|
|
|
|
answers |
int |
|
|
|
|
interesting |
int |
|
|
|
|
adoption |
int |
|
|
|
|
|
||
|
|
|
skills_bef |
int |
|
|
|
|
skills_aft |
int |
|
|
|
|
addition |
text |
|
|
|
|
comments |
text |
|
|
|
|
|
|
|
Рис. 4.4. Физическая схема данных для хранения анкетной информации
Задание 2. Создание БД из полученных моделей
Осуществите выгрузку окончательной схемы данных в БД под управлением СУБД PostgreSQL. Перед этим необходимо
создать в PostgreSQL новую БД, чтобы указать к ней путь в мастере выгрузки физических моделей ERMaster. Назовите эту БД anketa.
После выгрузки в созданной БД должны появиться восемь таблиц, соответствующих выгружаемой схеме данных, и взаимосвязи между ними на основе внешних ключей.
Скопируйте бинарный файл получившейся БД и передайте
его инженеру-программисту и руководителю проекта при помощи системы SVN.
33
ЛАБОРАТОРНАЯ РАБОТА № 5
РАЗРАБОТКА ПРОГРАММНОЙ ЛОГИКИ СИСТЕМЫ
5.1. Цель работы
Методической целью работы является получение теоретических знаний и практических навыков в разработке программных компонент веб-приложений на языке Java.
Практической целью является создание программного модуля системы анкетирования слушателей образовательных учреждений в режиме удаленного доступа, выполняющего следующие операции:
1.Обработка запросов от удаленных пользователей.
2.Соединение с БД.
3.Формирование и передача запросов к БД.
4.Получение и обработка ответов от БД.
5.Формирование конечного результата и передача его
удаленным пользователям.
5.2. Теоретические сведения, необходимые для выполнения работы
Систему анкетирования слушателей в режиме удаленного доступа, представляющую собой веб-приложение, будем разрабатывать при помощи фреймворка JSF, что позволит реализовать в
разрабатываемой системе шаблон архитектуры MVC (Model-View- Controller) и обеспечить четкое разделение бизнес-логики и логики
представления.
JSF – фреймворк, разработанный для облегчения процесса построения веб-приложений на основе технологий сервлетов и JSP. Обеспечивает стандартные тэги JSP и API, помогающие в управлении сложными формами HTML, деятельностью по обработке событий, и представлению данных.
Сервлет – программа на языке Java, расширяющая функциональные возможности веб-сервера. Основные функции сервлета –
34
получение от удаленных пользователей запросов (request) по протоколу HTTP и отправка обратно ответов (response) по тому же
протоколу.
JSP (Java Server Page) – страница, интерпретируемая браузером и представляющая собой код HTML с внедренным в него
при помощи специальных тэгов кодом Java.
MVC – сокращение от Model-View-Controller, архитектурный шаблон, с помощью которого модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделяются на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на остальные.
На рис. 5.1 представлены компоненты разрабатываемой системы с точки зрения архитектуры MVC.
HTML-браузер
ПК клиента
Controller
Faces Servlet
|
|
JSF-приложение |
|
|
|||
|
|
|
|
|
|
|
|
|
|
View |
|
|
Model |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HTML Render |
|
|
|
|
|
|
|
Kit |
|
|
|
|
|
|
|
|
|
|
|
AnketaForZan.class |
БД |
|
|
|
|
|
|||
|
|
|
|
|
AnketaLecData.class |
|
|
index.jsp |
|
|
DisciplineBean.class |
|
|||
|
welcome_student.jsp |
|
|
Lection.class |
|
||
|
welcome_student.jsp |
|
|
Login.class |
|
||
|
AnkensMenu.xhtml |
|
|
Seminar.class |
|
||
|
AnketaForLec.xhtml |
|
|
StudentBean.class |
|
||
AnketaForSem.xhtml StudentsAuthGroup.class
Zanyatie.class
ZanyatieBean.class
Рис. 5.1. Разрабатываемая система с точки зрения архитектуры MVC
На рис. 5.2 представлено архитектурное описание деятельности по разработке программной логики системы.
На рис. 5.3 представлено дерево каталогов веб-приложения, представляющего собой разрабатываемую в учебном проекте систему.
35
Рис. 5.2. Деятельность по разработке программной логики
Веб-приложение включает следующие основные каталоги:
Web Pages – каталог, содержащий совокупность вебстраниц, представляющих собой интерфейс пользователя;
Source Packages – каталог, содержащий Java-
программы, представляющие собой бизнес-модель приложения;
Libraries – каталог, содержащий набор библиотек Java API, фреймворка JSF, драйвера к БД и т.п.;
Configuration Files – каталог, содержащий
конфигурационные файлы веб-приложения, в которых прописываются данные по структуре, развертыванию, безопасности, администрированию веб-приложения.
36
Рис. 5.3. Дерево каталогов веб-приложения
5.3. Рабочие задания
Ниже представлены задания, которые необходимо выпол-
нить для достижения цели, поставленной в данной работе.
37
Для выполнения заданий сначала нужно создать в среде Eclipse веб-проект, в котором затем создавать Java-классы и страницы .jsp, .xhtml согласно заданиям.
Примечание. Для студентов младших курсов, изучающих дисциплину «Информатика», скриншоты кода будут даны преподавателем. Для них основной задачей будет только правильное написание этого кода и его отладка.
Задание 1. Программные компоненты для авторизации пользователей
Основная страница веб-приложения носит название index.jsp. Она является стартовой и при ее загрузке в браузере пользователь наблюдает окно, представленное на рис. 3.2 в разделе «Разработка пользовательского интерфейса» настоящего учебного
пособия.
Обработку данных со страницы index.jsp выполняет класс Login.class. Основными его задачами являются осуществление
валидации полей формы по нулевым значениям и проверка наличия имени и пароля пользователя в БД. За валидацию
введенных значений отвечает следующий код класса Login
(рис. 5.4).
Рис. 5.4. Программный код валидации данных
Из примера кода видно, что если пользователь оставил хотя бы одно поле (Имя или Пароль) пустым, то программа выдаст в окно браузера соответствующее сообщение об ошибке. Если оба
38
поля заполнены, программа считывает введенные значения,
соединяется с БД и посылает ей запрос на поиск значений. В БД для данного случая всего два значения – student и expert. Если
пользовательские данные совпали со строкой БД student, то метод класса Login выдает значение success_student, если с expert, то success_expert (рис. 5.5).
Рис. 5.5. Программный код поиска введенных значений в БД
На основе выданного классом Login значения механизм JSF осуществляет навигацию. Конфигурация навигации прописывается в файле faces-config.xml (рис. 5.6). Как видно из скриншота файла, навигация осуществляется следующим образом: если пользователь «залогинился» под именем student, то переход осуществляется на
страницу welcome_student, если под именем expert – на страницу welcome_expert.
Страница welcome_student выдает пользователю окно формы, соответствующее представленному на рис. 3.3 в разделе «Разработка пользовательского интерфейса» настоящего учебного пособия. При помощи этой формы студент должен выбрать из
39
списка свою группу, ФИО и ввести номер зачетки в качестве пароля. Если номер зачетки совпадет с номером для данных ФИО в БД, то авторизация пройдет успешно и пользователь будет переведен на страницу с выбором занятия для анкетирования.
Рис. 5.6. Навигация на основе значения, возвращаемого классом Login
Страница welcome_student работает с классом StudentsAuthGroup (см. рис. 5.3), отвечающим за вывод списка
групп и ФИО студентов, а также за проверку введенного
студентом значения номера зачетной книжки. При правильности введенных данных метод класса выдает значение success_StAuth,
на основе которого осуществляется навигация на страницу
AnketsMenu.xhtml (рис. 5.7).
Рис. 5.7. Навигация на основе значения, возвращаемого классом
StudentsAuthGroup
40