Содержание
Оглавление
Список терминов и сокращений4
Введение6
Глава 1. Аналитическая часть8
1.1. Технико-экономическая характеристика предметной области и предприятия. Анализ деятельности «КАК ЕСТЬ»8
1.1.1. Характеристика предприятия и его деятельности9
1.1.2. Программная и техническая архитектура ИС на предприятии, использование их функциональных возможностей. Обеспечение информационной безопасности.11
1.1.3. Структурно-функциональная диаграмма организации деятельности «КАК ЕСТЬ»12
1.2. Характеристика комплекса задач, задачи и обоснование необходимости автоматизации17
1.2.1. Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов18
1.2.2. Обоснования необходимости использования вычислительной техники для решения задачи19
1.2.3. Описание свойств ИС, требуемых для решения выбранной задачи19
1.3. Анализ существующих разработок и выбор стратегии автоматизации «КАК ДОЛЖНО БЫТЬ»24
1.3.1. Модель «TO-BE»24
1.3.2. Выбор и обоснование стратегии автоматизации задачи27
1.4. Развёрнутая постановка целей, задачи и подзадач автоматизации28
1.4.1. Трансформация базовой технологии решения задачи28
1.4.2. Цели и назначение автоматизированного варианта решения задачи29
1.4.3. Подзадачи автоматизации и функциональная информационная технология их решения30
1.5. Обоснование проектных решений31
1.5.1. Обоснование проектных решений по техническому обеспечению31
1.5.2. Обоснование проектных решений по информационному обеспечению32
1.5.3. Обоснование проектных решений по программному обеспечению36
Глава 2. Проектная часть37
2.1. Разработка проекта автоматизации: информационный менеджмент37
2.1.1. Этапы жизненного цикла проекта автоматизации37
2.1.2. Разработка и описание проекта автоматизации, плана-графика автоматизации и сетевой модели задач.40
2.1.3. Характеристика архитектуры разрабатываемого проекта.41
2.1.4. Характеристика этапа внедрения разрабатываемого проекта42
2.1.5. Характеристика этапа эксплуатации разрабатываемого проекта и возможных работ43
2.1.6. Ожидаемые риски на этапах жизненного цикла и их описание45
2.2. Информационное обеспечение задачи46
2.2.1. Информационная модель и её описание46
2.2.2. Характеристика нормативно-справочной, входной и оперативной информации46
2.2.3. Характеристика результатной информации49
2.3. Программное обеспечение задачи51
2.3.1. Общие положения (дерево функций и сценарий диалога)51
2.3.2. Характеристика базы данных57
2.3.3. Структурная схема пакета (дерево вызова программных модулей). Описание программных модулей.63
2.4. Технологическое обеспечение задачи64
2.4.1. Организация технологии сбора, передачи, обработки и выдачи информации64
2.4.2. Схемы технологического процесса сбора, передачи, обработки и выдачи информации65
2.5. Контрольный пример реализации проекта и его описание65
Глава 3. Обоснование экономической эффективности проекта67
3.1 Выбор и обоснование методики расчёта экономической эффективности67
3.2. Расчёт показателей экономической эффективности проекта.72
3.2.1. Материальные затраты.73
3.2.2. Затраты на оплату труда74
3.2.3. Амортизация основных фондов.76
3.2.4. Смета затрат.77
3.2.5. Оценка эффективности разработки проекта.78
Заключение84
Используемая литература86
Приложения87
Модель «AS-IS» деятельности предприятия до введения системы учета. Декомпозиция.87
Модель «TO-BE» деятельности предприятия после введения автоматизированной системы учета. Декомпозиция.91
План-график работ95
Сценарий диалогов96
Информационная модель97
Инфологическая модель.98
Структурная схема дерева вызова модулей100
Печатные формы документов101
Выдержка из текста работы
Сегодня трудно представить себе человека без мобильного устройства. Мы привыкли к тому, что оно всегда у нас под рукой. Теперь это не просто средство общения, а многофункциональное, многозадачное устройство.
Смартфоны, а также персональные компьютеры, обладают различными операционными системами или, как их еще называют, платформами. Поскольку мобильные продажи во всем мире растут, это непременно ведет к росту спроса на различные приложения для них. Теперь почти каждая компания стремится иметь, по меньшей мере, одно мобильное приложение. А существование некоторых компаний сложно представить без мобильных и специализированных приложений, с помощью которых можно, например, управлять данными или состоянием своего продукта на рынке в любой момент времени.
Устройства становятся все более и более персонализированными с возможностью доступа к ним в любое время из любого места. На переднем плане этого процесса стоят мобильные устройства, которые трансформируются в вычислительные платформы, выполняющие широкий спектр вычислительных задач, эти устройства становятся новым поколением персональных компьютеров.
Сейчас в индустрии информационных технологий увеличивается объем программного обеспечения для мобильных устройств. Эта тенденция открывает большие возможности как для разработчиков, так и для потребителей, конечных пользователей. Соответственно, на сегодняшний день разработка мобильных приложений как никогда актуальна.
Целью данной выпускной квалификационной работы является разработка информационно — справочной системы для одной из самых популярных в мире мобильных платформ — Android.
1. Аналитический обзор
.1 Постановка задачи
В качестве направления разработки мною была выбрана тема разработки мобильных приложений. На мой взгляд, эта тема очень актуальна в наше время. Прежде всего актуальность обусловлена популярностью мобильных устройств: смартфонов, планшетов и других портативных устройств.
Мобильные устройства, в особенности смартфоны — наши постоянные спутники, и мы постоянно ими пользуемся. Ведь действительно, люди со смартфонами повсюду. В некоторых европейских городах власти даже установили дорожные знаки, информирующие участников дорожного движения о людях, идущих со смартфонами.
Смартфон уже давно перестал быть роскошью, а рынок изобилует огромным количеством различных устройств. Так, согласно подсчетам и оценкам компаний, занимающихся аналитической деятельностью, в частности таких, как International Data Corporation, Json & Partners Consulting и Связной, в 2016 году объем российского рынка мобильных устройств в натуральном выражении составил около 30 миллионов устройств. Если сравнивать с предыдущим годом, то рынок вырос в среднем на 4,4 % [1].
Таким образом, наблюдается огромный спрос на смартфоны, и это неотъемлемо ведёт к огромному спросу на мобильные приложения. В подтверждение вышесказанному ниже приведены еще некоторые интересные аналитические данные.
Например, согласно данным исследовательской компании Forrester, люди берут в руки свои мобильные устройства в среднем от 150 до 200 раз в день, в результате получается почти 30 миллиардов случаев использования мобильных устройств в сутки [1].
Когда мы говорим о смартфонах, то нельзя обойти стороной их операционные системы — программное обеспечение, предназначенное для управления ресурсами устройства и организации взаимодействия с пользователем.
На сегодняшний день самыми популярными мобильными операционными системами или, говоря языком разработчиков, платформами являются:
—Android компании Google;
—iOS компании Apple;
Windows Phone компании Microsoft.
Дальше приведена статистика использования каждой из вышеперечисленных операционных систем в мире и в России, предоставленная веб-сервисом StatCounter, который анализирует веб-трафик [2].
Итак, в январе 2017-го в мире были зафиксированы следующие значения распространённости операционных систем в процентах, где в скобках показаны изменения, произошедшие за год: Windows Phone — 1.13% (-0.11%), iOS — 19.73 (+0.84%), Android — 71.58% (-0.39%). Ниже для наглядности приведено изображение, на котором расположен график популярности ОС в мире с января 2016 года по январь 2017 года.
Рисунок 1.1 — Мировая популярность мобильных операционных систем
В России мобильные устройства на Windows Phone составляют 2.54% (-0.3%), iOS — 26.56% (+1.04%), Android — 68.87% (-0.32%). Ниже также для наглядности приведено изображение.
Рисунок 1.2 — Популярность мобильных операционных систем в России
Таким образом, лидирующую позицию занимает операционная система Android, которую выбрали около 70% пользователей, второе место занимает iOS, последнее — Windows Phone.
Исходя из всего вышеперечисленного, можно сделать вывод, что мобильные приложения для устройств с операционной системой Android на сегодняшний день чрезвычайно популярны, а, следовательно, и их разработка является актуальной.
Далее будет рассмотрен вопрос того, что конкретно необходимо сделать в данной работе.
Итак, если говорить в общих чертах, то в данной работе необходимо разработать мобильное приложение под названием "Афиша города" для платформы Android, которое предоставляет актуальную информацию о событиях, происходящих в городе.
Событие — это некоторое явление, происшествие, мероприятие, которое имеет свое место и время. Это могут быть кинопоказы, театральные выступления, выставки, концерты и другие.
Детальное описание функциональных требований приведено в следующей главе, а здесь приведены основные функциональные возможности, которые необходимо реализовать в рамках работы:
—отображение списка событий;
—просмотр конкретного события;
поиск конкретного события;
добавление события календарь;
возможность поделиться событием в социальных сетях;
возможность посмотреть место проведения события на карте;
возможность сохранить понравившееся событие.
Кроме того, приложения должно иметь ряд ограничений, которые связаны с тем, что в последнее время наблюдается тенденция того, что аудитория хочет получить легкодоступный контент, как можно быстрее; необходимо обеспечить приложение рядом особенностей:
—интеграция с популярными приложениями;
—отсутствие регистрации;
простота и удобство интерфейса пользователя;
наличие интернет соединения.
Говоря о том, что хочет аудитория, нельзя обойти стороной вопрос: для кого это приложения? Вообще приложение может быть интересно многим пользователям. Оно может быть интересно как активным людям, людям, которые любят посещать различные мероприятия, будь то кино, выставки или музыкальные концерты, так и людям, которым просто интересно, что происходит в их городе.
Таким образом, в результате работы должно быть реализовано приложения о событиях города для операционной системы Android, которое должно полностью удовлетворять заявленным требованиям.
1.2 Анализ похожих решений
Для того, чтобы проанализировать похожие решения, их нужно определить. Для этих целей можно воспользоваться сервисом Google Play — магазином приложений, позволяющим владельцам устройств с операционной системой Android приобретать различные приложения [3].
Согласно результатам поиска в сервисе, самыми популярными приложениями данной категории в России являются:
—Афиша;
Первое приложение установили себе на устройство 1 миллион пользователей, второе — 100 тысяч.
В целом, функциональные возможности этих приложений схожи между собой. Однако, есть ряд особенностей, которыми они отличаются друг от друга, в частности, в приложении "Афиша" есть возможность покупки билета, а в приложении "KudaGo" можно посмотреть карту, на которой отмечены места проведения событий.
Ниже приведена таблица, в которой отмечены основные функциональные возможности и их наличие или отсутствие в каждом из приложений. Наличие возможности в таблице отмечено знаком "+", а отсутствие — знаком "-".
Таблица 1.1 — Сравнение функциональных возможностей приложений
Функциональная возможностьНаличие или отсутствие функциональной возможностиАфишаKudaGoПросмотр списка событий++Просмотр конкретного события++Функциональная возможностьАфишаKudaGoПоиск событий++Возможность фильтрации++Возможность поделиться событием в социальных сетях++Просмотр места проведения события на карте++Возможность сохранить событие++Возможность добавить событие в календарь-+Просмотр событий по категориям++Возможность зарегистрироваться и оставлять отзывы++Возможность оценить событие и посмотреть рейтинг+-
Глядя на таблицу, можно сделать вывод, что приложения обладают довольно схожим функционалом.
Кроме всего прочего, приложения довольно быстрые и удобные, ими приятно пользоваться. Хорошие оценки и отзывы в магазине Google Play это подтверждают: 4.3 из 5 стоит у приложения "Афиша", и 4.4 у приложения "KudaGo".
2. Проектирование системы
.1 Определение требований
Анализ требований — это одна из частей процесса разработки программного обеспечения, которая включает в себя сбор требований к программному обеспечению, их дальнейшую систематизацию, выявление взаимосвязей между ними , а также документирование.
На основании анализа предметной области и обзора похожих решений был выделен ряд функциональных требований к системе — требований, которые описывают то, что необходимо реализовать в системе. Они перечислены и описаны в таблице ниже.
Таблица 2.1 — Функциональные требования
№ТребованиеОписание требования1Просмотр списка событийПользователь должен иметь возможность просматривать список событий, при этом в начале должны отображаться самые новые события (события с самой последней датой регистрации). События, которые уже прошли, отображать не нужно.2Просмотр конкретного событияПользователь должен иметь возможность посмотреть конкретное событие. При детальном просмотре должны отображаться следующие атрибуты события: название, описание, время начала, время окончания, место проведения на карте, фотографии.3Поиск конкретного событияПользователь должен иметь возможность искать интересующие его события по названию, по дате проведения, но не считая прошедшие события.4Возможность добавить событие в календарь Пользователь должен иметь возможность добавить событие в календарь, при этом поля: название, время и место при добавлении события в календарь должны автоматически заполняться.5Возможность поделиться событием в социальных сетяхПользователь должен иметь возможность поделиться событием в социальных сетях, отправив ссылку на событие с сообщением: "Смотри, что будет у нас в городе". Возможные социальные сети: Вконтакте, Telegram, Twitter.6Возможность посмотреть место проведения события на картеПользователь должен иметь возможность посмотреть место проведения события на карте. На карте в месте проведения события должна стоять соответствующая отметка (маркер).7Возможность сохранить событиеПользователь должен иметь возможность сохранить понравившееся ему событие в соответствующий список, который затем можно отдельно посмотреть. Также должна быть предусмотрена возможность удаления сохраненных событий из этого списка.8Отсутствие регистрацииЧтобы пользоваться всеми возможностями приложения, пользователь не должен регистрироваться. Регистрация в приложении не предусмотрена.
К разрабатываемой системе также определен ряд нефункциональных требований — требований, которые описывают то, как должна работать система и какими свойствами или характеристиками она должна обладать. Эти требования перечислены и описаны в таблице ниже.
Таблица 2.2 — Нефункциональные требования
№ТребованиеОписание требования1Удобство использованияС точки зрения пользователя приложения должно быть удобным и интуитивно понятным.2ДоступностьПриложение должно быть доступным. Система не должна превышать максимально допустимое время простоя.3НадежностьПриложения должно быть надежным. Система должна вести себя адекватно в нештатных ситуациях.4БезопасностьПриложения должно быть безопасным. Необходимо обеспечить выполнение требований, связанных с разграничением доступа, требований, связанных с работой с приватными данным, и требований, направленных на снижение рисков от внешних атак.5ПроизводительностьПриложение должно быть производительным. Система должна обеспечивать время отклика не более 30 секунд.
Таким образом, к системе определены функциональные и нефункциональные требования, на следующем этапе будет разработана её структурно — функциональная модель.
2.2 Разработка структурно-функциональной модели
В качестве архитектуры для данной системы подходит классическая клиент — серверная (веб) архитектура.
Клиент — серверная архитектура — это вычислительная или сетевая архитектура, в которой вычисления распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами.
В нашем случае клиентом будет выступать мобильное приложение, а сервером — отдельное приложение, которое будет запущено на выделенном сервере и будет в свою очередь обращаться в API других сайтов (например, сайт https://vk.com) за данными.
API-набор готовых методов, предоставляемых приложением (библиотекой, сервисом) или операционной системой для использования во внешних программных продуктах.
Общую структуру системы можно представить следующим образом:
Рисунок 2.1 — Общая структура системы
Исходя из всего вышеописанного можно выделить следующие структурные элементы в системе:
—пользователь;
—мобильное приложение;
другие мобильные приложения;
сервер.
Пользователь взаимодействует с приложением, которое в свою очередь будет обращаться к серверу за необходимыми данными или обмениваться данными с другими установленными на устройстве мобильными приложениями, например такими, как Google Календарь, Вконтакте, Telegram, Twitter.
Структурно — функциональная модель системы представлена в приложении 1.
2.3 Разработка модели данных
На данном этапе в качестве модели данных было принято решение выделить всего одну основную сущность под названием "Событие". Это решение обусловлено прежде всего отказом от необходимости регистрации пользователя, что в свою очередь привело к сокращению хранимых и передаваемых данных.
Кроме того для хранения данных о месте проведения события была выделена дополнительная сущность под названием "Место".
Ниже в таблицах 2.3 и 2.4 приведены атрибутные составы этих сущностей.
Таблица 2.3 — Атрибутный состав сущности "Событие"
№Название атрибутаТип данныхОписание1idЦелочисленныйИдентификатор события2nameСтроковыйНазвание события3descriptionСтроковыйОписание события4imageСтроковыйСсылка на изображение5linkСтроковыйСсылка на сайт (страницу) события6startDateДата и времяДата и время начала события7endDateДата и времяДата и время окончания события8placeТип данных "Место"Место проведения события
Таблица 2.4 — Атрибутный состав сущности "Место"
№Название атрибутаТип данныхОписание1idЦелочисленныйИдентификатор места2nameСтроковыйНазвание места3latitudeЧисло с плавающей точкойКоордината широты места на карте4longitudeЧисло с плавающей точкойКоордината долготы места на карте
В приложении 2 представлена UML — диаграмма приведенных выше сущностей.
2.4 Выбор инструментальных средств
Для системы необходимо разработать как серверную, так и клиентскую части, и это требует ответственного отношения к выбору инструментальных средств анализа, проектирования, разработки и сборки разрабатываемого проекта.
Для написания серверной части был выбран язык программирования Java и написанный на нем фреймворк Jooby.
Язык Java — это объектно-ориентированный строго типизированный язык программирования, который обладает большой вычислительной мощностью, производительностью, переносимостью. Язык хорошо поддерживается разработчиками, имеет обширную документацию и постоянно развивается. Для выполнения программ, написанных на Java, требуется специальная виртуальная машина, что является ключевой особенностью языка.
Фреймворк — это готовый набор решений конкретной задачи или проблемы, чаще всего использующий простую концептуальную структуру.
Jooby — это фреймворк, который обладает довольно простой и эффективной программной моделью для разработки как маленьких, так и больших веб-приложений. Jooby имеет простую систему маршрутизации и способен работать с различными серверами, базами данных, сессией, средствами безопасности, системами кэширования и многим другим благодаря концепции модулей. Если необходимо подключить базу данных, то нужно просто определить соответствующий модуль и настроить его в специальном файле [4].
Клиентская часть, а точнее приложение для платформы Android, разрабатывается с помощью набора программных средств для разработки гибридных приложений таких, как:
—Cordova;
—Ionic;
—Angular2.
Гибридное приложение — это приложение, написанное с использованием технологий HTML, CSS и JavaScript, которое в конечном счете трансформируется в мобильное приложение.
Cordova — это утилита, которая осуществляет сборку приложения в готовый пакет мобильного приложения. Поддерживаемые платформы: iOS, Android, Windows Phone, Browser. Для платформы Android пакет будет иметь расширение apk (формат архивных исполняемых файлов-приложений для ОС Android) [5].
Angular2 — это фреймворк для создания различных приложений: мобильных, веб-приложений и приложений для настольного компьютера. Он написан на языке TypeScript и его ключевой особенностью является повторное использование компонентов, внедрение зависимостей и делегирование бизнес — логики в специальные сервисы. Компонент в Angular2 — это совокупность шаблона (представления) и кода, который его контролирует. Внедрение зависимости — это процесс предоставления внешней зависимости программному компоненту [6].
TypeScript — это расширение языка JavaScript, позволяющее писать код в объектно-ориентированном стиле и определять типы данных, как в статически-типизированных языках [7].
Фреймворк Ionic предоставляет набор готовых компонентов Angular2, стилей для проектирования интерфейса мобильного приложения. Это могут быть компоненты навигации в мобильном приложении, контекстного меню, всплывающих окон и другие полезные компоненты. Для каждой мобильной платформы определены свои стили [8].
3. Программная реализация
.1 Определение программных модулей
Модуль — это ключевой концепт для создания многократно используемых и настраиваемых частей программного обеспечения.
Как было отмечено в предыдущей главе, для реализации серверной части используется веб — фреймворк Jooby, написанный на Java. Фреймворк сам по себе состоит из модулей, которые представляют собой Java — классы, реализующие интерфейс Module.
Jooby поддерживает большой набор готовых к использованию модулей, помимо этого есть возможность определять свои.
При реализации серверной части были использованы следующие программные модули:
—Модуль App;
—Модуль Auth;
Модуль Jackson;
Модуль Vk.
App — это главный модуль приложения, который содержит в себе другие модули и является точкой входа в приложение. В этом модуле происходит определение и конфигурация других модулей, а также определяются маршруты (адреса) к API приложения, реализующие методы GET, POST, PUT, DELETE протокола HTTP посредством переопределения соответствующих методов get(), post(), put(), delete() класса Router.
Auth — это готовый модуль аутентификации, при помощи которого можно защитить API серверного приложения от несанкционированного доступа. Этот модуль является оберткой над популярной java-библиотекой безопасности pac4j, которая в свою очередь поддерживает различные клиенты и протоколы аутентификации. В нашем случае, в качестве протокола аутентификации выступает OAuth — открытый протокол, который позволяет третьей стороне получить доступ к защищенным ресурсам без необходимости передавать логин и пароль.
Jackson — это готовый модуль, который автоматически приводит содержимое (тело) приходящих на сервер приложений HTTP-запросов, а также отправляемых с него ответов в формат JSON. JSON — это удобочитаемый текстовый формат обмена данными, основанный на JavaScript. Этот формат отлично подходит для взаимодействия клиентской и серверной частей системы, так как клиентская часть написана на языке JavaScript имеющем встроенную поддержку данного формата.
Vk — это модуль, позволяющий взаимодействовать с API сайта Вконтакте через java-библиотеку, которую предоставляют разработчики данной социальной сети. В данном API интерес представляют два класса: Search и Group. Методы первого класса позволяют найти с помощью глобального поиска все события (встречи), получить их идентификаторы, а затем с помощью методов класса Group по идентификатору получить информацию о событии [9].
Структурная схема Jooby — модулей представлена на изображении ниже.
Клиентская часть реализована при помощи фреймворка Angular2, который также обладает модульной системой.
Модуль Angular2 — это класс, который помечен декоратором @NgModule, принимающим метаданные, которые подсказывают компилятору, как компилировать и запускать данный модуль. Он в свою очередь идентифицирует свои компоненты и сервисы, делая их доступными модулю, который его использует.
Следующие модули Angular2 были использованы при разработке:
—AppModule
—IonicModule
BrowserModule
—HttpModule
LocalStorageModule
AgmCoreModule
AppModule — это главный модуль Angular2 приложения. Он содержит в себе другие модули и является входной точкой в приложение. Все создаваемые компоненты и услуги содержатся и поставляются данным модулем.
IonicModule — это модуль, который занимается начальной загрузкой всех компонентов и сервисов фреймворка Ionic. Все компоненты и сервисы становятся доступными в главном модуле. Именно этот модуль определяет внешний вид гибридного приложения.
BrowserModule — это модуль, позволяющий корректно отобразить запущенное Angular2 приложение в браузере.
HttpModule — это модуль доступа к web. Данный модуль обладает набором сервисов, при помощи которых можно отправлять HTTP-запросы на сервера и получать HTTP-ответы. Запросы можно отправлять как синхронно, так и асинхронно. Преимущество асинхронных запросов в том, что они позволяют не прерывать поток выполнения приложения, а доверить результат запроса специальному объекту Promise, из которого затем можно извлечь соответствующий ответ, если он успешен, иначе обработать ошибку.
LocalStorageModule — это модуль, реализующий локальное хранилище данных, которое позволяет хранить данные в веб-браузере. При помощи этого модуля реализовано хранение мероприятий (событий) на мобильном устройстве.
AgmCoreModule — это модуль, реализующий API Google Карты. Данный модуль предоставляет готовый компонент AgmMap, с помощью которого можно отобразить карты, а также компонент AgmMarker, который представляет собой маркер в определенном месте карты. Для того, чтобы задать точку на карте, необходимо инициализировать атрибуты latitude (широта) и longitude (долгота) этих компонентов.
Структурная схема Angular2 — модулей представлена на изображении ниже.
Рисунок 3.2 — Структурная схема модулей
Листинг программного кода с объявлением модулей приведен в приложении 3.
.2 Разработка алгоритмов
В общем случае функционирование системы можно представить следующей схемой.
Мобильное приложение при помощи методов модуля HttpModule отправляет асинхронный HTTP — запрос на сервер. В результате вызова методов этого модуля HttpModule возвращается объект Promise, который имеет две функции обратного вызова (callback), которые срабатывают в случаях, если запрос выполнен успешно или с ошибками. Благодаря асинхронному запросу интерфейс приложения не блокируется [10].
Рисунок 3.3 — Общая схема функционирования системы
Сервер предоставляет мобильному приложению свое API для получения списка событий, события по идентификатору, по имени и т. п. Он настроен таким образом, что прослушивает приходящие на него запросы и передает их маршрутизатору, в котором описаны маршруты приложения.
Маршрут описывает интерфейс, на который направляются запросы к приложению. Он сочетает в себе HTTP — метод и шаблон пути (path pattern, url). Маршрут имеет ассоциированный с ним обработчик, который выполняет какую — либо работу и производит выходные данные, HTTP — ответ.
Обработчик в нашем случае обращается к API сайта Вконтакте при помощи модуля Vk, получает оттуда запрашиваемые данные и формирует ответ мобильному приложению.
Формирование ответа происходит после того, как получен ответ от сервера Вконтакте и включает в себя маппинг (отображение состояния одного объекта на состояние другого) полученных данных в объект события Event, который в дальнейшем при помощи модуля Jackson преобразуется в формат для передачи данных JSON.
Сформированный ответ направляется обратно мобильному приложению в виде HTTP — ответа с содержимым в виде JSON — объекта. Обработчик асинхронного запроса, инициированного в мобильном приложении, срабатывает и приложение отображает полученные данные в своем интерфейсе.
Таким образом можно описать общий алгоритм работы системы, но помимо этого, стоит более подробно остановиться на следующих алгоритмах системы:
—алгоритм получения списка событий с помощью API сайта Вконтакте;
—алгоритм поиска события в мобильном приложении.
Алгоритм получения списка событий с помощью API сайта Вконтакте описан ниже.
Сначала, для того, чтобы получить доступ к API сайта Вконтакте, необходимо создать новое приложение на странице приложений сайта Вконтакте и получить специальные ключи: APP_ID (идентификатор приложения), CLIENT_SECRET (секретный ключ) и REDIRECT_URI (доверенный адрес переадресации).
Далее нужно создать экземпляр специального объекта API VkApiClient, передав в него любой подходящий транспортный клиент, например HttpTransportClient и пройти авторизацию с помощью механизма Authorization Code Flow, основанного на технологии OAuth []. После этого в GET запросе будет получен специальный ключ «code», который необходимо передать в метод userAuthorizationCodeFlow() в качестве параметра вместе с другими: APP_ID, CLIENT_SECRET и REDIRECT_URI. В результате выполнения метода будет возвращен объект класса UserAuthResponse, при помощью которого создается класс UserActor. UserActor — это пользователь, от имени которого можно обращаться к API Вконтакте [9].
Часть алгоритма, связанная с авторизацией, выполняется администратором после запуска сервера.
Для того, чтобы получить список событий или точнее список групп Вконтакте с типом event, нужно сначала их найти. Для этого следует обратиться от имени пользователя к методу getHints() объекта Search API с параметром фильтрации, установленным в значение groups и параметром global_search, равным 1. В результате будет возвращен массив «сырых» объектов, содержащих идентификаторы, из которого нужно извлечь группы.
Группы имеют идентификаторы. Для того, чтобы получить полную информацию о группе, нужно обратиться к методу getById() объекта Group API. Это необходимо сделать для каждого объекта, полученного в результате поиска. Таким образом будет получен список объектов Group. Объекты списка нужно преобразовать в объект Event. Для лучшего понимания ниже представлена блок — схема данного алгоритма.
Рисунок 3.4 — Блок — схема алгоритма получения списка событий с помощью API Вконтакте
Алгоритм поиска события в мобильном приложении описан ниже.
В мобильном приложении присутствует функция поиска событий по названию. Когда пользователь вводит какой — либо символ или последовательность символов, то ему возвращается список с мероприятиями, в названиях которых содержатся данные символы. Для этих целей используются асинхронные запросы к API нашего сервера, которые возвращают объекты Observable, вместо Promise.
Observable — это поток каких-либо, который можно обрабатывать операторами, которые применимы к массиву. Данный объект позволяет создавать запрос, отменять его не дожидаясь ответа и затем создавать новый. Такой механизм трудно реализовать с помощью Promise [11].
Когда пользователь вводит символ в специальном окне ввода компонента приложения, то компонент прослушивает событие keyUp (нажатие клавиши), и прежде чем на сервер отправляется запрос, приложение ожидает 300 миллисекунд для того, чтобы не делать частые запросы. Запрос не отправляется, если пользователь ввёл символ, соответствующий предыдущему.
Рисунок 3.5 — Блок — схема алгоритма поиска событий в мобильном приложении
В результате запроса возвращается список объектов Observable, который с помощью оператора приведения преобразуются в список объектов Event, список может быть пустым. Если в результате произошла ошибка, то также возвращается пустой список мероприятий.
Блок — схема алгоритма представлена на изображении 3.5 на следующей странице.
Таким образом, в этом разделе были рассмотрены алгоритмы приложения, особое внимание было уделено алгоритмам обращения к API сайта Вконтакте и поиска события в мобильном приложении. Остальные алгоритмы, используемые в приложении, были уже реализованы фреймворками.
В приложении 4 представлены листинги кода реализованных алгоритмов системы.
.3 Особенности программной реализации
Главной особенностью программной реализации, на мой взгляд, является модульность и использование готовых решений: библиотек, фреймворков, инструментов. Модульность позволяет повторно использовать какие — либо части программной системы и настраивать их определенным образом. При реализации серверной части был использован модульный фреймворк Jooby, а при реализации клиентской — Angular2. Подобные средства позволяют «не изобретать велосипед заново», а использовать надежное, качественное, чётко — структурированное решение конкретной проблемы, реализованное и поддерживаемое профессиональными разработчиками.
Еще одной особенностью является использование объектно — ориентированных языков программирования (ООП) c возможностями функциональных языков программирования, таких как Java (версия 8) и TypeScript. ООП позволяет выделять реальные объекты окружающего мира и работать с ними, определив их состояния и поведения. Так, в проекте были выделены два объекта Event и Place, представляющие городское мероприятие и место его проведения. Функциональное программирование повышает надёжность кода и позволяет применять к программам достаточно сложные методы автоматической оптимизации, улучшая тем самым производительность.
Еще одной особенностью реализации является использование сетевой клиент — серверной архитектуры. Для передачи данных между клиентом и сервером применяется повсеместно используемый протокол прикладного уровня HTTP.
Особенностью серверной части является использование встроенного в приложение сервера приложений. Это означает, что приложение не нужно разворачивать на каком — то отдельном сервере приложений, а достаточно его (приложение) запустить, следом за ним запустится встроенный сервер, прослушивающий входящие запросы на настроенном имени хоста и порту.
Клиентское приложение на платформе Android особенно тем, что является гибридным. Оно основано на технологиях HTML, CSS и JavaScript и их расширений, с помощью которых создается веб — проект. Затем этот проект с помощью специальной программной утилиты Cordova собирается в готовый пакет приложения Android.
Таким образом, были рассмотрены основные особенности программной реализации системы.
4. Тестирование
.1 Функциональное тестирование
Функциональное тестирование — это тестирование программного обеспечения, целью которого является проверка реализуемости функциональных требований, то есть способности программного обеспечения в определенных условиях решать заявленные задачи.
Функционал серверной части информационно — справочной системы тестировался при помощи модульных и интеграционных тестов. Модульное тестирование — это тестирование отдельного компонента системы в изоляции от других. Интеграционное — это тестирование, при котором отдельные компоненты объединяются и тестируются в месте.
Основная часть функционала системы была реализована в клиентском приложении.
Рисунок 4.1 — Просмотр списка событий и детальный просмотр
Рисунок 4.2 — Просмотр места проведения событий на карте и поиск
Рисунок 4.3 — Возможность поделиться в соц. сетях и сохранить событие
На рисунках 4.1 — 4.3 следующей страницы приведены изображения интерфейса приложения на платформе Android с реализованными функциями, такими, как: просмотр списка событий, просмотр конкретного события с отметкой на карте, поиск конкретного события, возможность добавить событие в календарь, возможность поделиться событием в социальных сетях, возможность сохранить событие.
Приложение тестировалось в эмуляторе, поэтому некоторые функции протестировать не удалось, в частности: возможность поделиться событием в социальных сетях и добавление события в календарь; на устройстве данные функции полностью поддерживаются.
.2 Тестирование производительности
Тестирование производительности — это тестирование, которое проводится с целью определения времени работы программного обеспечения или его части под определенной нагрузкой. Оно также может служить для проверки и подтверждения других показателей системы, таких как масштабируемость, надёжность и потребление ресурсов.
Тестирование системы на производительность в нашем случае может носить только оценочных характер, так как тестирование проводилось на локальной машине. Развертывании системы на более мощных серверах может повысить показатели.
Тестировалась серверная часть системы, то есть получение списка событий, получение события по идентификатору, получение события по названию.
Тестирование производительности проводилось с помощью свободно — распространяемого инструмента для нагрузочного тестирования Apache JMeter, в конфигурации перед запуском тестов которого указываются группа потоков (количество пользователей), шаблон запроса (тип запроса, хост, порт и шаблон пути) и таймер (время паузы между запросами) [12].
В качестве шаблона запроса к API системы был HTTP — запрос типа GET со следующими шаблонами пути (id — число, идентификатор события, name — строка, название события):
