Разработка веб-приложения для интерактивных занятий со студентами

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

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждениевысшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Информационных систем и технологий

Направление Информатика и вычислительная техника

Кафедра Информатики и вычислительной техники

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Разработка веб-приложения для интерактивных занятий со студентами

В.С. Антимонов

Самара 2017



Содержание

Введение

1. Интерактивное обучение в высшем образовании

1.1 Интерактивные формы, методы и средства обучения

1.2 Постановка задачи

2. Веб-приложения на Java

2.1 Структура веб - приложений

2.2 Серверы корпоративных веб-приложений

3. Проектирование и разработка веб-приложения

3.1 Среда разработки и средства проектирования

3.2 Система сборки Maven

3.3 Библиотека JUnit для тестирования проекта

3.4 Сервер веб-приложенийJetty

3.5 Сетевая библиотекаNetty для работы с JavaNIO2

3.6 Проектирование и реализациявеб-приложения

Заключение



Введение

Внедрение Федеральных государственных образовательных стандартов Высшего образования (ФГОС ВО) на основе компетентностного подхода актуализировало значимость применения образовательных технологий и интерактивных методов в процессе обучения.

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

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

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

Преподавание, открытое в коммуникативном плане, характеризуют следующие утверждения:

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

2. Обучающиеся лучше учатся, если преподаватель активно поддерживает их способ усвоения знаний.

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

Переход на компетентностный подход при организации процесса обучения предусматривает широкое использование в учебном процессе активных и интерактивных форм проведения занятий (компьютерных симуляций, деловых и ролевых игр, разбора конкретных ситуаций, психологических и иных тренингов) в сочетании с внеаудиторной работой. Удельный вес занятий, проводимых в интерактивных формах… в учебном процессе, должен составлять не менее 20 процентов аудиторных занятий. (ФГОС, 7 раздел «Требования к условиям реализации основных образовательных программ», п. 7.3).

Всё вышесказанное определило актуальность темы работы - Разработка web-приложения для проведения интерактивных занятий со студентами.

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

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

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

Объектом исследования выступаютсредства и методы ведения интерактивных занятий со студентами в вузах.

Предмет исследования: применение программного обеспечения в этой отрасли.

Основными источниками для написания работы послужили книги по разработке на Java Б. Эккеля, К. Хорстмана, Г. Шилдта, статьи по ученому процессу в высших учебных заведениях.

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

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

Вторая глава раскрывает обзор средств и методов для решения поставленной задачи.

Третья глава раскрывает процесс проектирования, разработки ПО, и пуско-наладку рабочего окружения.

В заключении сделаны основные выводы и результаты по проделанной работе.



1. Интерактивное обучение в высшем образовании

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

Слово «интерактив» пришло к нам из английского от слова «interact». «Inter» - это «взаимный», «act» - действовать. Интерактивность - это способность взаимодействовать или находиться в режиме беседы, диалога с кем-либо (человеком) или чем-либо (например, компьютером).

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

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

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

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

Интерактивные формы проведения занятий:

ѕ пробуждают у обучающихся интерес;

ѕ поощряют активное участие каждого в учебном процессе;

ѕ обращаются к чувствам каждого обучающегося;

ѕ способствуют эффективному усвоению учебного материала;

ѕ оказывают многоплановое воздействие на обучающихся;

ѕ осуществляют обратную связь (ответная реакция аудитории);

ѕ формируют у обучающихся мнения и отношения;

ѕ формируют жизненные навыки;

ѕ способствуют изменению поведения.

Заметим, что важнейшее условие для этого -- личный опыт участия преподавателя в тренинговых занятиях по интерактиву. Научиться им можно только путем личного участия в игре, «мозговом штурме» или дискуссии.

1.1 Интерактивные формы, методы и средства обучения

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

Существуют следующие возможные варианты средств и форм интерактивного обучения:

1. Бинарная лекция (лекция-диалог).

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

2. Брифинг.

Брифинг - (англ. briefing от англ. brief -- короткий, недолгий) -- краткая пресс- конференция, посвященная одному вопросу. Основное отличие: отсутствует презентационная часть. То есть практически сразу идут ответы на вопросы журналистов.

3. Вебинар.

Вебинар (от слов "веб" и "семинар") -- это «виртуальный» практикум, организованный посредством Интернет-технологий. Вебинару присущ главный признак практикума -- интерактивность. Вы делаете доклад, слушатели задают вопросы, а вы отвечаете на них. Наиболее легкий способ организовать вебинар -- воспользоваться услугами компаний, специализирующихся на оказание данных услуг.

4. Видео-конференция.

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

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

5. Видео-лекция.

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

6. Виртуальная консультация.

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

7. Виртуальный тьюториал.

Используется для закрепления и корректировки самостоятельно полученных знаний и умений, выработки навыков групповой деятельности и обмена опытом с другими участниками. Тьюториалы проводятся с применением активных методов обучения (групповые дискуссии, деловые игры, решение кейсов, тренинги и мозговые штурмы).

Формы и методы этим не ограничиваются, рассмотрим подробнее такую форму, как вебинар, т.к. она может включать в себя все остальные.

Вебинар (от слов "веб" и "семинар") -- это «виртуальный» семинар, организованный посредством Интернет-технологий. Вебинару присущ главный признак семинара -- интерактивность. Иначе говоря, вы делаете доклад, слушатели задают вопросы, а вы отвечаете на них. Наиболее легкий способ организовать вебинар -- воспользоваться услугами компаний, специализирующихся на оказание данных услуг.

Преимущества вебинара.

Вебинар обладает всеми преимуществами своего «старшего брата» семинара, кроме возможности «кулуарного» общения между "посетителями", а также «живого» общения между ними же и докладчиком (что особенно критично для харизматичных ораторов).

Это, пожалуй, единственные существенные недостатки вебинаров, а плюсов гораздо больше:

1. Затраты на организацию у вебинаров существенно ниже (не надо арендовать зал, оборудование, не надо заказывать кейтеринг).

2. Высокая доступность для «посещения» слушателями (не надо покупать билеты на поезд или самолет).

3. Значительная экономия времени на организацию.

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

5. Интерактивное взаимодействие между докладчиком и «посетителями, а также «посетителями» между собой.

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

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

Советы по организации успешных вебинаров:

1.Заранее оповещайте потенциальных слушателей о дате и времени вебинара.

2.Запустите рекламную кампанию вебинара.

3.Спланируйте удобное время для вебинара.

4.Выработайте метрики для измерения эффективности вебинара

5.Проведите тестовый запуск вебинара.

6.Преподнесите интересную информацию.

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

7.Не бойтесь использовать много текста.

Любой опытный докладчик скажет вам, что в Power-Point презентации надо свести к минимуму текстовую информацию и перенести акцент на картинки, схемы и графики. Все это верно для «реальных» докладов, где оратор часто переносит внимание с экрана на себя, сами слова на экране плохо видны, и люди лучше воспринимают картинки и схемы. В вебинарах использование текста не столь критично, поэтому вы можете смело увеличить «дозу» символьной информации в ваших слайдах.

8.Проверьте своего докладчика.

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

9.Один хорошо, а двое лучше.

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

10.Провоцируйте обсуждения.

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

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

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

конкретному обучающемуся:

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

ѕ развитие личностной рефлексии как будущего профессионала в своей профессии;

ѕ освоение нового опыта профессионального взаимодействия с практиками в этой области; учебной группе:

ѕ развитие навыков общения и взаимодействия в малой группе;

ѕ формирование ценностно-ориентационного единства группы;

ѕ поощрение к гибкой смене социальных ролей в зависимости от ситуации;

ѕ принятие нравственных норм и правил совместной деятельности;

ѕ развитие навыков анализа и самоанализа в процессе групповой рефлексии;

ѕ развитие способности разрешать конфликты, способности к компромиссам;

системе преподаватель - группа

ѕ нестандартное отношение к организации образовательного процесса;

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



1.2 Постановка задачи

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

ѕ Спроектировать архитектуру приложения;

ѕ Выбрать инструменты и методы реализации на языке Java;

ѕ По возможности следует реализовать приложение таким образом, чтобы его можно было легко обновлять при необходимости, а также в случае, если код приложения понадобится внедрить в другой проект;

ѕ Приложение не должно обладать другими избыточными функциями;

ѕ Приложение должно быть легко масштабируемо и дополняемо;

ѕ Код должен быть снабжен документацией и комментариями;

ѕ Архитектура приложения должна быть понятной, логичной и обоснованной;

ѕ Реализовать веб-интерфейс приложения

ѕ Реализовать приложение в формате трехзвенной архитектуры

ѕ Работу клиента и сервера производить через специальный протокол

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

ѕ Хранение объектов в БД

ѕ Загрузка объектов из БД при запуске приложения

ѕ Реализовать бизнес-логику с учетом разработки в перспективе иного интерфейса, к примеру, для мобильных устройств.

ѕ Возможность проведения видеоконференций и вебинаров

ѕ Функция чата и рассылок

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

ѕ Сохранение видео с занятий

ѕ Иные возможности на усмотрение разработчика;

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



2. Веб-приложения на Java

Веб-приложение Java создает интерактивные веб-страницы, содержащие различные типы языков разметки (HTML, XML и т.д.), а также динамическое содержимое. Это содержимое обычно формируется веб-компонентами, например, страницами JavaServer (JSP), сервлетами и компонентами JavaBean, которые позволяют изменять данные и осуществлять их временное хранение, взаимодействовать с базами данных и веб-службами, а также отображать содержимое в ответ на запросы клиентов. [2]

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

Java EE (Enterprise Edition) представляет собой широко используемую платформу, содержащую набор взаимосвязанных технологий, которые существенно сокращают стоимость и сложность разработки, развертывания многоуровневых серверных приложений, а также управления ими. Платформа Java EE основана на платформе Java SE и предоставляет набор интерфейсов API (интерфейсов разработки приложений) для разработки и запуска портируемых, надежных, масштабируемых и безопасных серверных приложений.

Java EE в числе прочих содержит следующие компоненты: [2]

Enterprise JavaBeans (EJB): управляемая серверная архитектура компонентов, используемая для инкапсуляции бизнес-логики приложения. Технология EJB позволяет осуществлять быструю и упрощенную разработку распределенных, транзакционных, безопасных и переносимых приложений, основанных на технологии Java.

Интерфейс API сохранения состояния Java (Java Persistence API, JPA): инфраструктура, позволяющая разработчикам управлять данными с помощью объектно-реляционного сопоставления (ORM) в приложениях, созданных на платформе Java.

2.1 Структура веб - приложений

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

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

Рассмотрим отдельно задачу построения иерархической структуры работ. Каждое web-приложение можно представить в следующем виде:

Рис. 2.1 - Обобщенная структура корпоративного приложения

Другими словами, каждое web-приложение отправляет http запросы на web-сервер для получения полезных данных. Программа под управлением web-сервера использует ту или иную модель для хранения данных. В современном мире чаще всего используются базы данных, SQL или NoSQL.

Формально каждое web-приложение можно разбить на 3 взаимно независимые части.

ѕ Модуль, который исполняется WEB-браузером. Это приложение может быть написано на любом языке, который поддерживает браузер. Чаще всего используется язык JavaScript, как наиболее поддерживаемый и имеющий большую библиотечную поддержку. Это очень важно, так как позволяет существенно экономить бюджеты проектов.

ѕ Модуль, исполняемый на серверной стороне под управлением web-сервера. Это приложение может быть написано на любом языке, интерпретацию которого поддерживает выбранный Вами web-сервер. Последнее время, часто, в качестве языка программирования выбирается язык Java. Этот язык также имеет серьезную библиотечную поддержку.

ѕ База данных. В этой области так же существует достаточно широкий выбор. Есть промышленные базы данных, такие как Oracle, DB2, PostgreSQL. Есть легкие базы данных, такие как MySQL. База данных выбирается основываясь на целях и области решаемых задач.

Возможные эталонные модели проектирования web-приложений.

При построении архитектуры web -- приложения необходимо максимально уменьшить зависимость между структурными единицами. В общем случае приложение состоит из трех структурных единиц.

Рис. 2.2 - Модель проектирования веб-приложения

ѕ Модуль, который работает под управлением браузера.

ѕ Модуль, который работает под управлением web-сервера.

ѕ База данных.

Эти структурные единицы порождают два вида связей.

ѕ Связь между браузером и серверной частью.

ѕ Связь между серверной частью и базой данных.

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

Браузер -- это прикладное программное обеспечение для просмотра web страниц.

HTML - это стандартный язык разметки документов. Большинство современных web-браузеров способны интерпретировать язык HTML.

Web сервер -- это программное обеспечение, которое способно принимать HTTP запросы от клиентов, обрабатывать их и отправлять ответ в соответствии со стандартом протокола.

База данных -- это представленная в объективной форме совокупность самостоятельных материалов, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью ЭВМ.

Минимизация зависимостей

Для минимизации зависимостей между «Браузером» и Web-сервером необходимо, чтобы язык разметки HTML был задействован только в браузере, а Web-сервер предоставлял интерфейс для получения необходимых данных для страницы.

Для решения этой задачи необходимо:

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

ѕ Определить API серверной части.

ѕ Выбрать протокол взаимодействия между серверной и клиентской частью. Создание протокола удобнее всего выбрать на базе XML, так как большинство современных браузеров имеют встроенную поддержку этого языка.

ѕ Написать документ, в котором будет изложен протокол.

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



Рис. 2.3 - Модель взаимодействия клиента с приложением

Далее «Браузер» преобразуется в UML диаграммы состояний. На этих диаграммах будет отражено, в каком случае вызывается тот или иной метод.

Данная модель достижима двумя путями

ѕ Программа, выполняемая «Браузером» написана на JavaScript и общается с Web-Сервером через AJAX, получая ответы в соответствие с определенным протоколом.

ѕ «Браузер» интерпретирует только HTML код, а преобразования происходят посредством XSLT преобразований на стороне Web-Сервера.

В каждом из этих случаев достигается разделение программной части Web-Сервера и «Браузера». Т.е используя данную модель возможно вносить изменения в структурную единицу для «Браузера» и не вызывать косвенных изменений в серверной части. Это очень важно, так как ведет к уменьшению затрат на обработку запросов на изменения. Это происходит в силу того, что изменения в одной структурной единицы не выходят за ее рамки.

Взаимодействие базы данных и web-сервера возможно организовать на основании двух принципиально разных сценариях:

ѕ Бизнес логика находится в базе данных.

ѕ Бизнес логика находится в коде web-сервера.

В первом случае база данных хранит данные и предоставляет интерфейс доступа к данным:

ѕ Выборка данных -- решается через представления.

ѕ Модификация данных -- решается через хранимые процедуры.

Программа для web-сервера является драйвером для доступа к бизнес-логике. Т.е она просто связывает Браузер с бизнес логикой, которая реализована в базе данных.

Во втором случае база данных хранит данные, и предоставляет прямой доступ к данным. Бизнес-логика реализована в коде web-сервера. В этом случае база данных предоставляет транзакции для проведения атомарных операций.

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

На основании изложенного выше материала иерархическая структура работ примет следующий вид:

ѕ Модуль для «Браузера».

ѕ Модуль для Web-Сервера.

ѕ Модуль для Базы данных.

ѕ Протокол обмена между модулем «Браузера» и Web-Сервером.

ѕ Интерфейс взаимодействия между модулем «Браузера» и Web-Сервером.

ѕ Интерфейс взаимодействия между Web-Сервером и Базой данных.

2.2 Серверы корпоративных веб-приложений

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

Сервер приложений -- это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено (рис. 2.4) в трехуровневой клиент-серверной архитектуре (3-tier):

Рис. 2.4 - Модель "сервер приложений".

Первый уровень, интерфейсный, как правило, графический (GUI).

Средний уровень, исполнимый программный код, размещенный обычно на выделенном сервере.

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

В сетевой среде сервер приложений является посредником между фронт-эндами клиентов и серверами баз данных.

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например, javascript, апплеты, flash).

Мобильный софт:

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

ѕ урезанная по функционалу клиентская часть получается менее требовательной к ресурсам;

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

ѕ изменения в программе (расширение функциональности, исправление ошибок и т. п.) выполняются на сервере приложений и распространяются на всех клиентов.

Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <--> контейнер сервлетов <--> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь -- через веб-сервер.

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

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

Поэтому, чтобы ответить на вопрос, является ли (и в какой степени) некое сервисное ПО сервером приложений, стоит сравнить его заявленные функции со списком атрибутов, присущих этой категории:

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

ѕ Предоставляет сервисные услуги для программ.

ѕ Обеспечивает управление приложениями и/или представляет средства их разработки.

ѕ Соответствует индустриальным спецификациям и стандартам.

ѕ Обслуживание веб-страниц, ввиду реальной востребованности технологий на основе WWW.

По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.

Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС.

Общий шлюзовый интерфейс (CGI) -- технология доступа к приложениям через веб-сервер. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout.

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

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

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

Примером реализации контейнера сервлетов является Apache TomCat, который используется в таких серверах приложений как Apache Geronimo, JBoss, GlassFish, IBM WebSphere Application Server (WAS).

Другие решения:

Компания Microsoft представляет собственные решения для поддержки бизнес-логики и сервисной инфрастуктуры на основе ОС Windows Server и технологии .NET Framework. Основным средством разработки является язык C#.

Язык python, получивший популярность во многом благодаря Google, является основным средством разработки для сервера веб-приложений Zope.

Для сценариев на языке PHP, широко используемом для создания веб-сайтов, компания Zend Technologies (разработчик самого языка PHP) создала сервер приложений Zend Server.

Преимущества:

Целостность кода и данных: Размещение бизнес-логики на выделенном сервере или ограниченном числе серверных компьютеров гарантирует доступ к обновленному и модернизированному ПО для всех клиентов. Это исключает риск доступа и управления данными из устаревших и, возможно, несовместимых программ.

Централизованное управление: Изменения в конфигурации прикладных программ, такие как, например, смена сервера баз данных, выполняются централизованно.

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

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

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

Недостатки

Централизация: Системы, построенные на основе сервера приложений, имеют один основной недостаток, присущий всем централизованным решениям -- «падение» сервера приведет к недоступности программ для всех клиентов. К тому же эффекту приведут и неполадки в сетевом подключении. Защита информации: Эта проблема, в принципе, актуальна для любых сетевых решений, использующих для передачи данных инфраструктуру публичных сетей.



3. Проектирование и разработка веб-приложения

3.1 Среда разработки и средства проектирования

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

Так, непосредственно для создания кода было решено выбрать среду IntelligIDEA. IDEA -- интегрированная среда разработки программного обеспечения на многих языках программирования, в частности Java, JavaScript, Python, разработанная компанией JetBrains. Первая версия IntelliJ IDEA появилась в январе 2001 года и быстро приобрела популярность, как первая Java IDE с широким набором интегрированных инструментов для рефакторинга, которые позволяли программистам быстро реорганизовывать исходные тексты программ. Дизайн среды ориентирован на продуктивность работы программистов, позволяя им сконцентрироваться на разработке функциональности, в то время как IntelliJ IDEA берёт на себя выполнение рутинных операций.

Рис. 3.1 - Скриншот рабочего окна IntelligIDEA



Системой управления версиями выбран Git, как отвечающий требованиям процесса разработки и, что упрощает работу, интегрированный в среду разработки IntellijIDEA при помощи специального плагина.

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

Комментарии документации применяют для документирования классов, интерфейсов, полей (переменных), конструкторов и методов.

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

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

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

Преимущества UML:

ѕ UML объектно-ориентирован;

ѕ UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

ѕ Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

ѕ UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;

UML получил широкое распространение и динамично развивается.

3.2 Система сборки Maven

Maven - это инструмент для сборки Java проекта: компиляции, создания jar, создания дистрибутива программы, генерации документации. Простые проекты можно собрать в командной строке. Если собирать большие проекты с командной строки, то команда для сборки будет очень длинной, поэтому её иногда записывают в bat/sh скрипт. Но такие скрипты зависят от платформы. Для того чтобы избавиться от этой зависимостии и упростить написание скрипта используют инструменты для сборки проекта.

Основные преимущества Maven:

ѕ Независимость от OS. Сборка проекта происходит в любой операционной системе. Файл проекта один и тот же.

ѕ Управление зависимостями. Редко какие проекты пишутся без использования сторонних библиотек(зависимостей). Эти сторонние библиотеки зачастую тоже в свою очередь используют библиотеки разных версий. Maven позволяет управлять такими сложными зависимостями. Что позволяет разрешать конфликты версий и в случае необходимости легко переходить на новые версии библиотек.

ѕ Возможна сборка из командной строки. Такое часто необходимо для автоматической сборки проекта на сервере (ContinuousIntegration).

ѕ Хорошая интеграция со средами разработки. Основные среды разработки на java легко открывают проекты которые собираются c помощью maven. При этом зачастую проект настраивать не нужно - он сразу готов к дальнейшей разработке.

ѕ Как следствие - если с проектом работают в разных средах разработки, то maven удобный способ хранения настроек. Настроечный файл среды разработки и для сборки один и тот же - меньше дублирования данных и соответственно ошибок.

ѕ Декларативное описание проекта.

pom.xml - это основной файл, который описывает проект. Вообще могут быть дополнительные файлы, но они играют второстепенную роль.

Состав файла pom.xml:

1. Корневой элемент и заголовок.

<modelVersion>4.0.0</modelVersion>

</project>

Корневойэлемент<project>, схема, котораяоблегчаетредактированиеипроверку, иверсия POM.

Внутри тэга project содержится основная и обязательная информация о проекте:

<!-- The Basics -->

<groupId>...</groupId>

<artifactId>...</artifactId>

<version>...</version>

ВMavenкаждыйпроектидентифицируетсяпаройgroupIdartifactId. Во избежание конфликта имён, groupId - наименование организации или подразделения и обычно действуют такие же правила как и при именовании пакетов в Java - записывают доменное имя организации или сайта проекта. artifactId - название проекта. Внутри тэга version, как можно догадаться хранится версия проекта. Тройкой groupId, artifactId, version (далее - GAV) можно однозначно идентифицировать jar файл приложения или библиотеки. Если состояние кода для проекта не зафиксировано, то в конце к имени версии добавляется "-SNAPSHOT" что обозначает, что версия в разработке и результирующий jar файл может меняться. <packaging>...</packaging>определяет какого типа файл будет создаваться как результат сборки. Возможные варианты pom, jar, war, ear

Давайте лучше рассмотрим на примере проекта powermock-coregroupId - org.powermock, artifactId - powermock-core , version - 1.4.6

Также добавляется информация, которая не используется самим mavenом, но нужна для программиста, чтобы понять, о чём этот проект:

<name>Trackcar</name> название проекта для человека

<description>GPSMonitor</description> Описание проекта

<url>localhost</url> сайт проекта.

Зависимости - следующая очень важная часть pom.xml - тут хранится список всех библиотек (зависимостей) которые используюся в проекте. Каждая библиотека идентифицируется также как и сам проект - тройкой groupId, artifactId, version (GAV). Объявление зависимостей заключено в тэг <dependencies>...</dependencies>.

<dependencies>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.4</version>

<scope>test</scope>

</dependency>

<dependency>

<groupId>org.powermock</groupId>

<artifactId>powermock-reflect</artifactId>

<version>${version}</version>

</dependency>

<dependency>

<groupId>org.javassist</groupId>

<artifactId>javassist</artifactId>

<version>3.13.0-GA</version>

<scope>compile</scope>

</dependency>

</dependencies>

Как можно заметить, кроме GAV при описании зависимости может присутствовать тэг <scope>. Scope задаёт, для чего библиотека используется. В данном примере говорится, что библиотека с GAVjunit:junit:4.4 нужна только для выполнения тестов.

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

<build>

<outputDirectory>target2</outputDirectory>

<finalName>ROOT</finalName>

<sourceDirectory>src/java</sourceDirectory>

<resources>

<resource>

<directory>${basedir}/src/java</directory>

<includes>

<include>**/*.properties</include>

</includes>

</resource>

</resources>

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-pmd-plugin</artifactId>

<version>2.4</version>

</plugin>

</plugins>

</build>

Рассмотрим пример более подробно.

<sourceDirectory> определяет, откуда maven будет брать файлы исходного кода. По умолчанию это src/main/java, но вы можете определить, где это удобно. Директория может быть только одна (без использования специальных плагинов)

<resources> и вложенные в неё тэги <resource> определяют, одну или несколько директорий, где хранятся файлы ресурсов. Ресурсы в отличие от файлов исходного кода при сборке просто копируются. Директория по умолчанию src/main/resources

<outputDirectory> определяет, в какую директорию компилятор будет сохранять результаты компиляции - *.class файлы. Значение по умолчанию - target/classes

<finalName> - имя результирующего jar (war, ear) файла с соответствующим типу расширением, который создаётся на фазе package. Значение по умолчанию -- artifactId-version.

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

ѕ Основные фазы сборки проекта:

ѕ Compile Компилирование проекта

ѕ Test Тестирование с помощью JUnit тестов

ѕ Package Создание .jar файла или war, ear в зависимости от типа проекта

ѕ integration-test Запуск интеграционных тестов

ѕ install Копирование .jar (war , ear) в локальный репозиторий

ѕ deploy публикация файла в удалённый репозиторий

К примеру, нам нужно создать jar проекта. Чтобы его создать нужно задать команду:mvnpackage.

Но перед созданием jar-файла будут выполняться все предыдущие фазы compile и test, а фазы integration-test, install, deploy не выполнятся. Если набрать mvndeploy, то выполнятся все приведённые выше фазы.

Особняком стоят фазы clean и site. Они не выполняются, если специально не указаны в строке запуска.

Clean - удаление всех созданных в процессе сборки артефактов: .class, .jar и др. файлов. В простейшем случае результат -- просто удаление каталога target

Site - предназначена для создания документации (javadoc+сайт описания проекта) Т. к. команда mvn понимает, когда ему передают несколько фаз то для сборки проекта создания документации "с нуля" выполняют: mvncleanpackagesite

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

3.3 Библиотека JUnit для тестирования проекта

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

1) Для С++ была реализована CPPUnit;

2) JavaScript может использоваться совместно с JSUnit;

3) Для C# разработчики создали NUnit;

4) Perl скрипты можно тестировать с помощью Test::Unit;

5) PHP код могут тестировать с помощью PHPUnit модуля;

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

Метод assertFalse проверяет, является ли результат выражения в скобках неверным. При запуске теста последний пройдет успешно, т.к. результат - не равный. В классе "org.junit.Assert" предусмотрены и другие методы: интерактивный обучение приложение интерфейс

ѕ assertEquals(int1, int2) или утверждение эквивалентности. Проверяет на равенство двух значений любого примитивного типа;

ѕ assertFalse, assertTrue(condition) или булевые утверждения. Вместо “condition” необходимо вставить проверяемое условие;

ѕ assertNull, assertNotNull(obj) относятся к Null утверждениям и проверяет содержимое объектной переменной на Null значение;

ѕ assertSame(obj1, obj2) утверждение позволяет сравнивать объектные переменные.

Для каждого из assert-ов вы можете добавить первым параметром строку, которая выведется, если тест провалится: assertEquals (“Test is failed”, int1, int2).

Если какой-либо тест по какой-либо серьезной причине нужно отключить,nакже, если поместить аннотацию на класс, то все тесты в этом классе будут отключены. Помимо этого есть также аннотация @Test(timeout = 1000). По истечении указанного в скобках времени, если тест не пройден, он считается неудачным. Время указывается в миллисекундах.

В jUnit для задания определенных стартовых условиймогут пригодится т.н. фикстуры. Под этим термином следует понимать состояние среды тестирования, которое требуется для успешного выполнения тестового метода. Например, это может быть набор каких-либо объектов или состояние базы данных. Фикстуры помогают многократно использовать программный код за счет правила, которое гарантирует исполнение определенной логики до или после исполнения теста. В предшествующих версиях JUnit это правило неявно подразумевалось вне зависимости от реализации фикстур разработчиком. В версии JUnit 4 фикстуры указываются через аннотации: @Before, @After, @BeforeClass, @AfterClass.

@Before используется для выполнения множества предварительных условий перед выполнением теста. Например, если есть необходимость записать данные в БД или создать пользователя перед выполнением теста. Метод, помеченный @Before будет выполняться перед выполнением каждого теста в классе.

Метод, помеченный @After запускается после выполнения каждого теста. Например, если нужно очищать переменные после выполнения каждого теста, то этой аннотацией можно маркировать метод, имеющий необходимый код. Более того, можно маркировать одновременно несколько методов аннотациями @Before и @After. Однако, следует иметь в виду, что эти методы могут запускаться в различном порядке. Для задания многократных фикстур используются аннотации @Before и @After: его можно зааннотировать с помощью @Ignore.

Также есть такие аннотации, как @BeforeClass, @AfterClass (т.н. однократные фикстуры). Они необходимы, еслинужно вызвать фикстуру всего один раз. Еще jUnit предоставляет функцию параметризированного тестирования.

3.4 Сервер веб-приложенийJetty

Jetty -- не столько полноценный сервер приложений, сколько контейнер сервлетов, написанный полностью на Java. Может использоваться как HTTP-сервер или в паре со специализированным HTTP-сервером (к примеру, с ApacheHTTPServer). Первоначально распространялся под лицензией Apache 2.0 License, но после перехода в 2009 году в число приложений, разрабатываемых в рамках проекта Eclipse стал доступен и под EclipsePublicLicense (EPL).

...