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

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

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

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

Кафедра программного обеспечения и управления в технических системах

Выпускная квалификационная (бакалаврская) работа

На тему:

Клиентская часть приложения для совместного решения задач

Выполнил В.В. Островский,

студент группы ПО-32

Руководитель: доцент

к.т.н., И.А. Стефанова

Самара - 2017

ЗАДАНИЕ

по подготовке выпускной квалификационной работы

Студента Островского Владислава Вячеславовича

1. Тема ВКР: Клиентская часть приложения для совместного решения задач

Утверждена приказом по университету от 03.04.17 №74-2

2. Срок сдачи студентом законченной ВКР 09.06.17

3. Исходные данные и постановка задачи

1) техническое описание языка программирования JavaScript;

2) техническое описание ExtJS;

4) разработать многофункциональный web-интерфейс.

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

1) спроектировать клиентскую часть приложения с использованием языка программирования JavaScript;

2) изучить API для взаимодействия с сервером;

3) изучить способы отправки данных на сервер.

4. Перечень подлежащих разработке в ВКР вопросов или краткое содержание ВКР

рассмотреть основы передачи данных по сети;

проектирование клиентской части приложения;

реализация многофункционального web-интерфейса приложения;

тестирование клиентской части приложения.

5. Перечень графического материала

1) презентационные материалы;

2) диаграмма классов приложения.

6. Дата выдачи задания «5» апрель 2017 г.

Кафедра программного обеспечения и управления в технических системах

Утверждаю зав. кафедрой д.т.н., проф. В.Н. Тарасов

Руководитель доцент к.т.н., доц. И.А. Стефанова

Задание принял к исполнению В.В. Островский, студент группы ПО-32

ОТЗЫВ РУКОВОДИТЕЛЯ

Тип ВКР

Студента

Специальность/

направление

Тема ВКР: Клиентская часть приложения для совместного решения задач

Руководитель Стефанова Ирина Алексеевна

Ученая степень, звание к.т.н., доцент кафедры ПОУТС, ФГБОУ ВО ПГУТИ

Актуальность темы

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

Оценка содержания работы

(Структура, логика и стиль изложения представленного материала, глубина и степень проработки материала, обоснованность изложенных выводов, использование математического аппарата, использование средств вычислительной техники, макетирование, моделирование, экспериментирование)

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

Степень достижения цели и практическая значимость

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

Поставленные в бакалаврской работе задачи решены в полном объеме. Ценность работы для студента - изучение и применение на практике технологий для «front-end» разработки, языка программирования JavaScript и ряда его фреймворков. Знания и навыки, полученные в результате выполнения работы могут быть использованы в дальнейшей профессиональной деятельности будущего специалиста. Практическая ценность работы заключается в разработке клиентской части web-сервиса совместного решения задач.

Заключения по представленной работе

(Степень самостоятельной работы студента; совокупная оценка труда студента и его квалификация)

Разделы рассматриваемой бакалаврской работы проработаны Островским В.В. в полном объеме. В целом, бакалаврская работа соответствует требованиям, предъявляемым к ВКР, заслуживает оценки «отлично», а студенту Островскому Владиславу Вячеславовичу может быть присвоена степень бакалавра по направлению «Информатика и вычислительная техника».

Руководитель ВКР И.А. Стефанова

РЕФЕРАТ

Название Клиентская часть приложения для совестного решения задач

Автор Островский Владислав Вячеславович

Научный руководитель Стефанова Ирина Алексеевна

Ключевые слова приложение, клиентская часть, JavaScript, совместное решение задач

Дата публикации 2017

Библиографическое описание

Островский, В.В. Клиентская часть приложения для совместного решения задач [Текст]: бакалаврская работа / В.В. Островский. Поволжский государственный университет телекоммуникации и информатики (ПГУТИ). Факультет очного отделения (ФОО) Информатика и Вычислительная Техника (ИВТ): науч. рук. И.А. Стефанова - Самара. 2017.

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

ВВЕДЕНИЕ

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

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

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

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

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

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

Методологической основой для выпускной квалификационной работы являются книги следующих авторов: Никсон Робин «Создаем динамические веб-сайты», Дэвид Сойер JavaScript и jQuery. Исчерпывающее руководство 3-е издание, Кайл Симпсон ES6 и не только.

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

Для достижения данной цели требуется следующее:

1. Рассмотреть основных конкурентов на рынке;

2. Выбрать язык программирования;

3. Выбрать фреймворк обладающий всеми необходимыми возможностями;

4. Выбрать инструменты разработки;

5. Изучить основные протоколы передачи текста, аудио и графической информации;

6. Спроектировать интерфейс;

7. Разработать модуль авторизации пользователей;

8. Разработать модуль регистрации пользователей;

9. Разработать модуль основного, рабочего окна;

10. Разработать окно чата;

11. Разработать окно для рисования;

12. Добавить уведомления от пользователей;

13. Разработать меню отображения чатов;

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

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

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

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

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

2. Первая глава - структура системы;

3. Вторая глава - выбор инструментов для разработки программного обеспечения;

4. Третья глава - разработка клиентской части приложения;

5. Пятая глава - тестирование клиентской части и приложения в целом;

6. Заключение по бакалаврской работе;

7. Приложение содержат - исходный код программы

1. Структура системы

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

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

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

В данной работе используется технология клиент - серверного взаимодействия под названием REST. Сервер реализован в виде RESTfull web service. Для взаимодействия используются различные запросы основой для которых служит протокол HTTP с помощью которого передаются данные на сервер для получения на их основе ответных данных или получения данных без отправки данных непосредственно на сервер от клиента. Структура сервера представляет из себя набор конечных точек которые связаны с соответствующими методами на сервере. Каждая конечная точка выполняет одно действие по обработке данных с клиента либо предоставляет действия с данными.

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

Существует четыре модуля на сервере:

1. Модуль работы с пользователями;

2. Модуль работы с пакетами голосовых сообщений;

3. Модуль работы с геометрическими примитивами;

4. Модуль работы с текстовыми данными.

Также помимо четырех модулей приведённых выше существует слой доступа к данным. Слой доступа к данным реализован с помощью технологии ORM. Объекты модели на сервере имеют отображение с отношениями в базе данных приложения и выполняют CRUD операции автоматически. Для подключения к базе данных на сервере сконфигурирован Connection Pool, который создаёт подключения к базе данных и выдаёт их по запросу после чего хранит для предоставления одного и того же подключения еще раз. Это позволяет повысить производительность взаимодействия с базой данных, так как не требуется для подключения к базе данных создавать новое подключение, а можно использовать уже существующее. Такой подход позволяет, в том числе, и осуществлять контроль за максимальным количеством подключений и в случае необходимости увеличивать или уменьшать максимально возможное количество подключений к базе данных. Далее будет описана общая структура сервера с помощью UML диаграмм.

Для разработки клиента был использован JavaScript фрэймворк. Который позволяет поддерживать MVC архитектуру на клиенте. Что позволяет отделить модель данных от непосредственного их представления пользователям. Для этого предлагает изучить нам новые концепции построения интерфейсов с использованием MVC (рис. 1.1). Для того что представление могло взаимодействовать с данными мы можем воспользоваться хранилищем данных - Store, для модели данных которые будут загружены в Store с сервера предлагается использовать ViewModel и для связи пользовательского мы используем ViewController который связывает две части - представление и данные и предоставляет возможности двустороннего взаимодействия.

Рис. 1.1 - MVC архитектура

Рис. 1.2 - Схема работы приложения

2. Требования

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

Требования делятся на уровни:

· Бизнес-требования - определяют назначение ПО, описываются в документе о видении и границах проекта;

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

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

Требования делятся на несколько видов:

· Функциональный характер - требования к поведению системы;

· Нефункциональный характер - требования к характеру поведения системы.

К разрабатываемому приложению выделены следующие функциональные требования:

1. Приложение должно обеспечивать возможность коммуникации между пользователями. Можно выделить несколько способов:

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

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

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

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

3. Продукт должен иметь возможность авторизации и регистрации. Авторизация происходит за счет ввода двух полей:

· логин;

· пароль;

Регистрация происходит за счет ввода шести полей:

· фамилия;

· имя;

· отчество;

· логин;

· пароль;

· Email.

4. При авторизации и регистрации поля должны проверяться на правильность ввода.

Проверка при регистрации:

· emai у каждого пользователя должен быть уникальный;

· пароль состоять из шести символов минимум;

· логин у каждого пользователя должен быть уникальный.

Проверка при авторизации:

· корректность ввода логина;

· корректность ввода пароля.

К разрабатываемому приложению выделены следующие нефункциональные требования:

1. Безопасность - хранить и зашифровывать данные на сервере;

2. Интуитивно понятный интерфейс;

3. Быстрая скорость работы.

Все выше перечисленное является требованием к приложению в целом, что касается клиентской части это:

· форма авторизации;

· форма регистрации;

· валидация корректности ввода данных;

· отправка данных на сервер: Аудио, Текстовые, Графические;

· разработка пользовательского интерфейса;

· обработка нажатия на кнопки;

· разделение на группы.

Рис. 2.1 - Диаграмма классов «Клиента»

1.2 Модель данных

Модель данных представляет из себя набор объектов, которые отображают реальные объекты которыми оперирует система. Это объекты представляющие пользователя, текстовое сообщение, графическое сообщение и т.д. На серверной стороне модель данных в виде объектов представлена набором POJO(Plain Old Java Object) объектов. Программная модель данных отображается на модель базы данных где каждый класс - это таблица в базе данных, а каждый объект созданный на основе класса - это определённый кортеж значений из базы данных. Реализованная модель данных позволяет удобно обрабатывать данные оперируя не отдельными значениями в текстовом виде а объектами реального окружения. Это позволяет получать и изменять атрибуты, которые привязаны к конкретному экземпляру класса системы. Для удобства пересылки таких объектов используется формат JSON. JSON позволяет представить объект системы в текстовом виде и переслать объект по сети используя протокол HTTP. Также такой формат является удобным для восприятия человеком. В общем виде такие объекты выглядят как набор ключей и значений где ключ может являться еще одним объектом с набором ключей и значений. На стороне сервера реализована автоматическая конвертация POJO в JSON объекты при помощи библиотеки Jackson.

Примеры JSON объектов, пересылаемых между клиентом и сервером.

1. Текстовое

{

“message”: “Test message”

“sender”: “firstUser”

“receiver”: “secondUser”

}

2. Графическое сообщение

{ “x”: 10

“y”: 20

“type”: “circle”

“color”: “black”}

3. Выбор инструментов

3.1 Выбор языка программирования и фреймворка

Клиентская часть написана на языке программирования JavaScript с использованием фреймворка - Ext JS [1].

JavaScript - мультипарадигменный язык программирования. Поддерживает, объектноориентированный, императивный и функциональный стили. Является реализацией языка ECMAScript [2].

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

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

На JavaScript оказали влияние многие языки, при разработке была цель сделать язык похожим на Java, но при этом лёгким для использования непрограммистами. Языком JavaScript не владеет какая-либо компания или организация, что отличает его от ряда языков программирования, используемых в веб-разработке.

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

В языке отсутствуют такие полезные вещи как:

· модульная система: JavaScript не предоставляет возможности управлять зависимостями и изоляцией областей видимости;

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

· стандартные интерфейсы к веб-серверам и базам данных;

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

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

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

Ext JS - фреймворк JavaScript для разработки веб-приложений и пользовательских интерфейсов.

Библиотека Ext JS разбивается на две части:

1. Ext Core - Это главные модули. Функционал которых нужен для работы остальных компонентов библиотеки. То есть это набор JavaScript-функций, которые позволяют создавать динамические веб-страницы в различных браузерах.

2. Ext JS -набор виджетов для создания пользовательских интерфейсов.

Core разбит на несколько модулей:

· ядро - обеспечивает менеджер событий, работу с адаптерами и операции с DOM-моделью. В него включены все необходимые функции, например UpdateManager для обновления страницы по расписанию или событию (AJAX);

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

· утилиты -- добавляют функции работы с JSON, обработку CSS, работу с событиями клавиатуры и базовую поддержку шаблонов. В библиотеке существует собственная система шаблонов. Xtemplate - компонент для полноценного использования шаблонов [3];

· поддержка все браузеров вынесена в отдельный модуль -- часто можно, путем ограничения части функционала, увеличить производительность, отказавшись от Drag and Drop;

· компонент State Manager -- при входе все окна или вкладки будут восстановлены.

Работа с данными осуществляется с помощью двух форматов обмена данными с сервером -- JSON и XML.

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

1. Store(главный компонент) -- с ним работают объекты, которые хотят получить или отправить данные;

2. Reader - отвечает за структуру;

3. Proxy обеспечивает доступ к серверу через абстракцию Connection;

4. Record хранит набор записей из данных.

3.2 Выбор среды разработки

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

Для написание программного кода решение было принято в сторону среды разработки “WebStorm”.

WebStorm - интегрированная среда разработки на JavaScript, CSS и HTML. Также осуществляется поддержка языков программирования, таких как TypeScript, CoffeeScript, Dart, Less, Sass и Stylus и фреймворков - Angular, React, ExtJS и Meteor.

WebStorm была разработана на основе IntelliJ IDEA, компанией JetBrians. Среда разработки постоянно обновляется и улучшается тем самым захватывая рынок своим встроенным наборов инструментов, с помощью которых облегчают жизнь разработчикам, помогая делать их работу качественнее. Можно выделить следующие особенности WebStorm:

· отладка кода на JavaScript, ECMAScript; 2015+, TypeScript, CoffeeScript и Dart с использованием source maps;

· отладка Node.js приложений;

· интеграция с Git, GitHub, Subversion, Perforce, Mercurial, CVS;

· интеграция с системами отслеживания ошибок -ESLint, JSHint, JSLint, TSLint, Stylelint;

· Модификация файлов .css, .html, .js с одновременным просмотром результатов;

· Поддержка HTML5;

· Поддержка JSDoc;

· Поддержка Node.js;

· Возможности Zen Coding и Emmet;

· Интеграция с системами отслеживания ошибок;

· Встроенные инструменты для модульного тестирования;

· Поддержка Standard и опций форматирования кода, включая сортировку импортов;

· Автодополнение имен модулей в package.json;

· Исправление кода с помощью TSLint, интеграция с Angular language service;

· Новые диаграммы зависимостей, статус тестов прямо в редакторе;

· Поддержка эмодзи в редакторе.

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

3.3 Выбор системы управления версиями

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

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

Системой контроля и управления версий выбран - Git. Так как отвечает всем требованиям для разработки и интегрирован в среду разработки WebStorm, а также для git разработано огромное количество сервисов для хранения исходных данных.

Git - распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. На сегодняшний день его поддерживает Джунио Хамано.

Ключевые особенности Git:

· высокая производительность;

· развитые средства интеграции с другими подобными сервисами;

· программные средства позволяют разработчикам использовать git при размещении центрального репозитория в SVN или CVS, кроме того, git может имитировать cvs-сервер, обеспечивая работу через клиентские приложения и поддержку в средах разработки, специально не поддерживающих git(Рис. 3.3);

· продуманная система команд, позволяющая удобно встраивать git в скрипты;

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

Рис. 3.3 - Структура Git

3.4 Выбор инструмента для документирования

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

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

Существует четыре основных типа документации на ПО:

· архитектурная/проектная -- обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО;

· техническая -- документация на код, алгоритмы, интерфейсы, API;

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

· маркетинговая.

Документирование JavaScript-кода осуществляется при помощи синтаксиса языка - JSDoc. JSDoc - генератор документации из строк комментариев исходного кода на языке программирования JavaScript. JSDoc даёт возможность создавать доклеты и теги, которые могут встречаться в HTML, RTF. Следовательно, это минимизирует затраты времени на оформление комментариев и написание документации. JSDoc формирует HTML-файл, в которой написана вся документация, что является очень удобным, т.к. такой формат поддерживает любой веб-браузер и среда разработки WebStorm (Рис 3.4).

Рис 3.4 - Пример работы JSDoc

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

В разработке важно графическое представление приложения. Лучше всего для этого подходит язык UML. UML - унифицированный язык программирования, который графически описывает структуру программного обеспечения. UML создан для визуализации программных систем. Редактором для UML и других диаграмм был выбран - flowchart designer. Главным преимуществом является интуитивно понятный интерфейс, бесплатная версия, которая не урезает функционал и скорость работы.

Рис. 3.5 - Пример UML-диаграммы построенной в Flowchart designer

клиентский приложение коммуникация пользователь

4. Разработка

Вначале была выбрана модель разработки программного обеспеченья - Agile. Главное преимущество у данной модели это то, что она позволяет после каждой итерации наблюдать результаты. Недостатки это отсутствие конкретных формулировок результатов, из этого следует сложность в оценки трудозатрат, которые требует разработка. Также особенностью является непродолжительные ежедневные встречи -- «Scrum» и регулярно повторяющиеся собрания - «Sprint». На ежедневных совещаниях участники команды обсуждают:

· отчёт о проделанной работе с момента последнего Scrum'a;

· список задач, которые сотрудник должен выполнить до следующего собрания;

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

· потребности постоянно меняются;

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

В результате проектирования был разработан web-сервис и реализована клиентская часть - пользовательский интерфейс, формируют запросы к серверу и обрабатывает ответы от него.

Сервис для решения совместных задач разработан в виде одностраничного приложения. Одностраничное приложение это web-приложение (рис. 4.1), которое использует один HTML-документ как оболочку для всех страниц. Организация взаимодействия с пользователем происходить через постоянную под грузку: CSS, HTML, JavaScript. [4], [5] Благодаря такой реализации приложение схоже с интерфейсом «родных»(native) приложений. Отличие в том, что одностраничное приложение находится в рамках браузера, а не а операционной системе. Такой способ реализации делает взаимодействия с приложением привычным и удобным. Разработка производилась при помощи языка JavaScript и фреймворка Ext JS.

Рис. 4.1 - Взаимодействия Клиента с Сервером

4.1 Регистрация и авторизация

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

4.1.1 Регистрация

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

· фамилия;

· имя;

· отчество;

· логин;

· пароль;

· Email.

После заполнения всех данных нажимаем кнопку «зарегистрироваться» (Рис. 4.2). Данные отправляются на сервер. Он в свою очередь проверят данные на корректность. Если данные введены с ошибкой - email или логин ранее уже был использован, пароль недостаточно безопасен, то появляется сообщение об ошибки. В этом сообщение предлагают исправить некорректные данные. Так продолжается до тех пор пока все данные не будут введены верно.

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

Рис. 4.2 - Регистрация пользователя

Для реализации регистрации написана функция. Создана форма, которая содержит шесть текстовых поля. Также на кнопку «Зарегистрироваться» обработано событие, которое проверяет данные на корректность и отправляет их на сервер.

Для наглядного примера была разработана и изображена диаграмма действий (рис. 4.3)



Рис. 4.3 - Диаграмма действий регистрация

4.1.2 Авторизация пользователя

Для авторизация пользователя нужно ввести логин и пароль в соответствующие поля (Рис. 4.4). Данные отправляются на сервер. Он проверяет данные на корректность. Если была совершена ошибки, то выводит сообщение о не правильно вводе логина или пароля. [9]

Рис. 4.4 - Авторизация пользователя

Для реализации авторизации была написана функция.

Создана форма, которая содержит 2 текстовых поля. Также на кнопку «Зарегистрироваться» обработано событие, которое проверяет данные на корректность и отправляет их на сервер.

Также для защиты от несанкционированного доступа к странице пользователя предусмотрено перенаправление на страницу «авторизации».

Для наглядного примера была разработана и изображена диаграмма действий (рис. 4.5)

Рис. 4.5 - Диаграмма действий авторизации

4.1.3 Безопасность

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

· CSRF - Cross Site Request Forgery - вид атаки, которая использует недостаток протокола HTTP. Если пользователь заходит на сайт, который создал злоумышленник, то от его лица отправляется запрос на другой сервер, например на сервер платёжной системы и осуществляет операцию по переводу денег на чужой счёт. Чтоб организовать такую схему жертва должна быть авторизована на сервере куда отправляется запрос. Не мало важно, чтоб запрос не должен требовать подтверждения[6];

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

Для обработки и устранение таких «лазеек» обычно используют протокол OAuth 2.0.

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

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

Схема работы приложения с протоколом авторизации OAuth:

· Получение авторизации

· Обращение к защищенным ресурсам

Результат авторизации это access token -- ключ, который даёт доступ к защищённым ресурсам. Обращение к ним происходит по HTTPS с указанием в заголовках или в качестве одного из параметров полученного access token'а. В протоколе описано несколько вариантов авторизации, подходящих для различных ситуаций:

· Авторизация для приложений с серверной частью. Например: веб-сайты и веб-приложения

· Авторизация для клиентских приложений. Например: мобильные и desktop-приложения.

· Авторизация по логину и паролю

· Восстановление предыдущей авторизации

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

Для наглядного представления работы OAuth 2.0 представлено две схемы (рис. 4.6) (рис. 4.7)

Рис. 4.6 - Авторизация полностью клиентских приложений



Рис. 4.7 - Авторизация для приложений, имеющих серверную часть

4.2 Пользовательский интерфейс

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

Существует несколько типов интерфейсов:

· командный интерфейс - пользователь даёт команды, а устройство их выполняет. Например - командная строка;

· Window Image Menu Pointer (окно, образ, меню, указатель) - пользователь даёт команды через графические образы;

· Speech Image Language Knowlege (речь, образ, язык, знание) - приложение находит команд через анализ поведение пользователя. Например: речевая технология (Siri, Google Assistant), биометрическая (считывания с камеры), семантическая (искусственный интеллект);

· Веб-интерфейс - средства при помощи которых пользователь взаимодействует с веб-сайтом или веб-приложением через браузер [7].

«Приложения для совместного решения задач» это веб-приложение, следовательно, разработан веб-интерфейс. Пользовательский интерфейс (рис. 4.8) разработанного приложения включает в себя:

1. Панель вкладок с выбором диалогов;

2. Текстовое поле для отправки сообщений;

3. Текстовое поле для получения сообщений;

4. Графическое поле для рисования;

5. Кнопки: отправки аудио, текстового сообщений.

Рис. 4.8 - Пользовательский интерфейс

4.2.1 Панель вкладок с выбором диалогов

В приложение реализована возможность переходить в разные диалоги. Принцип работы можно создать или зайти в уже существующий диалог. Панель с существующими диалогами представляет собой набор кнопок, при нажатие которых отправляется запрос на сервер и клиент ждет ответ. [8] После чего отображает полученную информацию. При создание диалога нужно ввести его название. Для наглядного примера представлена диаграмма действий (рис. 4.9).

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

Рис.4.9 - Диаграмма действий выбора и создание диалогов

4.3 Способы коммуникации пользователей

Основополагающая возможность «Приложения для совместного решения задач» - это коммуникация между пользователями. Также важен выбор способа коммуникации. Для этого было реализованы следующие виды обмена информации:

· Текстовое сообщение;

· Аудио звонок;

· Графическое сообщение.

4.3.1 Текстовое сообщение

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

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

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

Чтоб наглядно объяснит отличие классической модели программирования сетевые приложений и модели приложений для сети на Ajax представлен рис. 4.3.1.1

Рис. 4.10 - Сравнение моделей программирования

4.3.2 Аудио звонок

Кроме способа передачи текстового сообщения в приложение реализована функция «Аудио звонок». Она позволяет в онлайн-режиме общаться сразу несколькими пользователями. Такой способ общения не является основным, но поддержка такого функционала неоспорима важна. Например: если идёт бурная дискуссия или отправка текстового сообщения может занять много времени, а объяснение на словах является более эффективным.

Принцип работы аудио сообщения - с микрофона, который подключён к устройству, считываются побайтово данные и отправляются на сервер. Также каждый клиент постоянно отправляет запрос на сервер для получения аудио-данных. (рис 4.11)

Рис. 4.11 Диаграмма действий аудио сообщения

4.3.3 Графическое сообщение

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

Рис. 4.12 - Пример геометрических фигур и связующих элементов

Созданные диаграммы можно отправлять другим пользователем, которые могут её редактировать. Такой способ помогает эмитировать «живое» взаимодействия между людьми.

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

Для наглядного примера представлена диаграмма действий (рис. 4.14).



Рис. 4.13 - Диаграмма действий графического сообщения

Рис. 4.14 - Графическое сообщение

5. Тестирование

Тестирование клиентской части и приложения в общем можно разделить на три части:

· Unit-тестирование (тестировал каждый компонент отдельный)

· Интеграционное тестирование (тестирование всех модулей + интеграция с серверов)

· Системное тестирование

· Тестирование пользовательского интерфейса

5.1 Unit-тестирование

Unit-тестирование это модульное тестирование. Оно позволяет автоматизировать процесс проведения тестов и протестировать каждую функцию программы отдельно. Для тестирования пишется код, которой воспроизводит ситуацию работы программы, например: отправка и получение данных с сервера. Модульное тестирование это первое тестирование, которые выявляет проблемы на стадии реализации отдельных функций. Такой подход не всегда эффективный, например для веб-сервисов, которые работают с большим объёмом статистики. В случае приложения для совместного решения задач такой подход необходим.

В разработанном клиенте реализовано несколько модулей:

· авторизации;

· регистрации;

· отправка тестового сообщения;

· отправка аудиосообщения;

· отправка графического сообщения;

· создание нового диалога;

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

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

· привычный стиль написания тестов - Класс теста, методы, набор assert»;

· Запуск JavaScript на всех браузерах одновременно;

· перехват сообщений об ошибках;

· вывод отчета на консоль;

· для написания тестов не нужен html, только js-файл. Это основное преимущество, так как приложение разрабатывается на ExtJ;

· легкая расширяемость - подключение любого js-модуля;

· формирование отчета;

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

5.1 - Пример кода тестирование

5.2 Интеграционное тестирование

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

Итог - интеграционное тестирование прошло успешно. Все модули работают.

5.3 Тестирование пользовательского интерфейса

Тестирование на удобства пользования или тестирование пользовательского интерфейса - выполняется для определения удобства взаимодействия пользователя с программой. Для проведение теста были привлечены люди, которые не принимали участие в разработке интерфейса. Наблюдая за тем как таксировщики взаимодействуют с приложение были выявлены проблема с пониманием интерфейса. [11] Также были проведены следующие виды тестирования:

· Тестирование на соответствие стандартам графических интерфейсов;

· Тестирование с различными разрешениями экрана;

· Совместимость с различными Интернет-браузерами;

· Тестирование локализованных версий: точность перевода, проверка длины названий элементов интерфейса;

· Тестирование графического интерфейса пользователя на целевых устройствах.

Итог - интерфейс был переработан и последующие тесты на удобство пользованием были пройдены.

5.4 Системное тестирование

Системное -- это тестирование программы в целом. Проверка работы клиента с сервером, например:

· Отправка данных на сервер, запись их в СУБД

· Приём и отображение данных с сервера

· Отображение данных в диалоговых окнах

· Передача файлов

Для автоматизации титрования есть два подхода:

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

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

В случае проверки «Приложения для совместных решения задач» было выбран самый простой и выгодный по времени способ - ручное тестирование. Ручное тестирование - производится таксировщиком без использования программных средств, путём моделирования и воспроизведения действий пользователя. [12]

Ход выполнение тестирования:

· Ввод данных в поля «Логин» «Пароль».

· Нажатие кнопки «Отправить». Результат - Ошибка (Неверный пароль или данный пользователь не существует).

· Нажатие кнопки «Отправить». Результат - Переход на главную страницу.

· Нажатие кнопки «Регистрация». Результат - переход на страницу с полями для ввода данных.

· Ввод данных в поля на странице «Авторизации».

· Нажатие кнопки «зарегистрироваться». Результат - Ошибка (email или логин заняты).

· Нажатие кнопки «зарегистрироваться». Результат - успешная регистрация.

Итог - приложение успешно прошло системное тестирование.

ЗАКЛЮЧЕНИЕ

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

В процессе проектирование разработки приложения были изучены фреймворк ExtJS, язык программирования JavaScript. Также была изучены части документаций по фреймворку и языку программирвования.

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

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

Размещено на Allbest.ru

...