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

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

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

Введение

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

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

Говоря о сайте НИУ ВШЭ, мы имеем ввиду мощный ресурс, обеспечивающий взаимодействие с целевой аудиторией, которую составляют студенты, выпускники, абитуриенты и сотрудники университета. На сегодняшний день это главный инструмент взаимодействия администрации ВУЗа с перечисленными выше представителями сообщества. Однако, не всегда информационные посылы доходят до потенциальных получателей без дополнительных средств оповещения, которые на сегодняшний день существуют, например, электронная почта. Это обусловлено тем, что студенты не часто заходят на информационный портал НИУ ВШЭ и не читают информацию, представленную на нем.

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

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

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

Объектом исследования является информирование студентов. Предметом исследования является автоматизация процесса оповещения студентов о поступившей на сайт информации.

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

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

1. Провести анализ предметной области. Построить модель оповещения (AS IS).

2. Изучить информацию о существующих технологиях оповещений.

3. Построить модель оповещения (TO-BE).

4. Сформулировать первичные требования к разрабатываемой системе.

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

6. Спроектировать мобильное приложение.

7. Разработать мобильное приложение.

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

1. Анализ предметной области

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

1.1 Описание предметной области

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

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

1.2 Описание пользователя

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

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

Группа «Студенты».

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

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

Предпочтения и потребности:

· как можно меньше вдаваться технические нюансы приложения;

· своевременно и бесперебойно получать необходимую информацию;

· предсказуемость приложения;

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

Группа «Абитуриенты».

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

Предпочтения и потребности:

· как можно меньше вдаваться технические нюансы приложения;

· своевременно и бесперебойно получать необходимую информацию;

· возможность подписки на одинаковые образовательные программы разных кампусов;

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

Группа «Преподавательский состав и администрация университета».

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

Предпочтения и потребности:

· как можно меньше вдаваться технические нюансы приложения;

· своевременно и бесперебойно получать необходимую информацию;

· возможность подписки на одинаковые образовательные программы разных кампусов;

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

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

1.3 Обзор существующих технологий оповещения

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

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

Например, официальное приложение известной в России и странах СНГ социальной сети vk.com использует технологию push-уведомлений для оповещения пользователей о получении сообщений, заявок в друзья и о других активностях, связанных с аккаунтом пользователя социальной сети. В этом случае, сервер vk.com генерирует сообщение об изменениях, связанных с аккаунтом пользователя. Тем временем, клиент, установленный на устройстве пользователя, производит мониторинг сервера на наличие сообщений с определенной периодичностью и, если сообщение найдено, производит оповещение путем отправки уведомления на экран пользователя.

1.4 Описание бизнес-процесса AS-IS

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

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

На текущий момент модель оповещения можно описать так, как показано на рис. 1.1. Бизнес-процесс описан с использованием нотации IDEF0.

Рисунок 1.1. Диаграмма бизнес-процесса «Модель оповещения» AS-IS

Администрация НИУ ВШЭ используя имеющуюся информацию, публикуют статьи на сайте НИУ ВШЭ. Важно отметить, что содержание данных статей, а также действий администрации регламентировано законами Российской Федерации и локальными нормативными актами НИУ ВШЭ. После публикации студент заходит на сайт и прочитывает статью.

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

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

Бизнес-процесс TO-BE описан с использованием нотации IDEF0 и представлен на рис. 1.2.

Рисунок 1.2. Диаграмма бизнес-процесса «Модель оповещения» TO-BE

Модель TO-BE в начале повторяет модель AS-IS в том, что администрация публикует информацию на сайте в виде статей под управлением законов Российской Федерации и локальных нормативных актов НИУ ВШЭ. В дальнейшем модель оповещения приобретает другие очертания. Мониторинг статей на сайте производит не студент, как это было раньше, а мобильное приложение. Управляется мобильное приложение внутренними инструкциями, а также пользовательскими настройками. Произведя мониторинг, система отправляет данные (результаты сканирования) пользователю, тем самым оповестив его об изменениях. После этого, студент имеет возможность открыть текст статьи и изучить ее в полном объеме.

Для более полного понимания процессов «Сканирование разделов сайта НИУ ВШЭ-Пермь» и «Оповещение пользователей», необходимо произвести декомпозицию описанных процессов.

Декомпозиция бизнес-процесса «Сканирование разделов сайта НИУ ВШЭ» представлена на рис. 1.3.

Рисунок 1.3. Декомпозиция бизнес-процесса "Сканирование разделов сайта НИУ ВШЭ"

Декомпозиция бизнес-процесса «Сканирование разделов сайта НИУ ВШЭ» позволила разделить его на три основных процесса. После того, как администрация университета публикует статьи, приложение, в соответствии с указанным в настройках интервалом времени, начинает сканирование разделов сайта, на которые подписан пользователь.

Первым этапом во всем процессе является проверка наличия Интернет-соединения. Сканирование разделов сайта НИУ ВШЭ невозможно без доступа к интернету. После того, как приложение получает результат проверки и интерпретирует его как положительный (устройство подключено к сети интернет), мобильное приложение начинает поиск последней ранее отсканированной статьи. Делается это для того, чтобы ограничить пределы сканирования. Получая ссылку на статью, приложение производит сканирование страниц начиная с первой статьи, следующей за той, которая была обнаружена на предыдущем этапе. Таким образом, бизнес-процесс формирует список статей, о которых пользователь еще не оповещался. Затем этот список передается в процесс «Оповещение пользователя», он представлен на рис. 1.4.

Рисунок 1.4. Декомпозиция бизнес-процесса "Оповещение пользователя"

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

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

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

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

1.6 Разработка требований к информационной системе

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

Требования к функциональным характеристикам.

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

1. Разделение пользователей, использующих мобильное приложение, по группам:

a. Кампус.

b. Академическая степень.

c. Факультет.

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

3. Возможность пользовательской настройки каждой отдельно взятой подписки по разделам и рубрикам.

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

5. Мониторинг страниц, на которые подписан пользователь, в фоновом режиме.

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

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

8. Возможность производить оповещение пользователя путем отправки ему push-уведомлений о наличии непрочитанных статей.

Требования к надежности.

К надежности разрабатываемой системы предъявляются следующие требования:

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

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

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

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

1.7 Анализ и выбор существующих технологий и продуктов

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

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

1. Осуществление сканирования данных в фоновом режиме.

2. Хранение информации.

3. Обработка текста статьи.

Осуществление сканирования данных в фоновом режиме.

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

В процессе изучения операционной системой для мобильных устройств Android, была выявлена собственная технология Android Service.

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

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

1. Мониторинг сайта НИУ ВШЭ в соответствии с заданным в настройках интервалом времени.

2. Опознавание новых статей, о которых пользователь ранее не уведомлялся.

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

4. Уведомлять процессы путем отправки push-уведомлений на экран устройства пользователя.

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

Хранение информации.

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

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

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

Для эффективного выбора технологии были сформированы критерии:

1. Простота внедрения.

2. Скорость работы.

3. Качество документационного сопровождения от разработчиков.

Выбор по критерию «Скорость работы».

Критерий «Скорость работы» является наиболее важным для разрабатываемого приложения, т.к. от скорости работы СУБД зависит скорость работы самого приложения.

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

Тестировались следующие ORM:

1. RealM.

2. OrmLite.

3. GreenDao.

4. DBFlow.

5. Cupboard.

6. Sprinkles.

7. ActiveAndroid.

8. Ollie.

9. Sugar ORM.

10. SQLite.

Результаты тестирования записи представлены на рис. 1.5.



Рисунок 1.5. Результаты тестирования записи в ORM

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

Из результатов видно, что лучшее время записи показали Realm, SQLite, GreenDao, DBFlow.

Результаты тестирования чтения представлены на рис. 1.6.

Рисунок 1.6. Результаты тестирования чтения из ORM

Из результатов видно, что на данном этапе также лучшими оказались Realm, SQLite, GreenDao, DBFlow. Дальнейший отбор продолжим с этими продуктами.

Выбор по критерию «Качество документационного сопровождения от разработчиков».

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

В процессе изучения документации, а именно ее качества, по описанным ранее продуктам было выявлено, что документация ORM DBFlow некачественная по следующим причинам:

1. Большая доля существующий официальной документации не актуальна для новейшей версии продукта.

2. Официальная документация не полная.

3. В официальной документации встречаются ошибки.

Таким образом, ORM DBFlow не может считаться претендентом на использование в проектируемом приложении.

Выбор по критерию «Простота внедрения».

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

Результаты отбора.

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

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

Обработка статьи.

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

В процессе поиска технологий, подходящей для удовлетворения этой потребности, была обнаружена библиотека, позволяющая удовлетворить потребность в обработки статьи с минимальными трудовыми затратами. JSOUP - Java-библиотека, позволяющая работать с реальным HTML. Предоставляет удобный API для извлечения и обработки данных, используя лучшие из DOM, CSS и Jquery-подобных методов.

Этот инструмент способен разобрать HTML-код из URL, файла или строки, а затем манипулировать атрибутами, текстом и/или элементами разметки. Данная библиотека очень проста в использовании и добилась признания среди множества разработчиков.

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

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

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

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

1. Eclipse.

2. Intellij IDEA.

3. Android Studio.

Наименее серьезным инструментов из представленных выше является Eclipse. Это обусловлено тем, что в Intellij IDEA и Android Studio реализованы такие мелочи, как автоматическое закрытие скобок после условия, автоматизировано создание шаблонных классов, а также имеются другие, на первый взгляд не очень важные функции. Однако, по статистике, наличие описанного функционала может сэкономить около 120 часов в год.

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

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

В процессе работы над главой, были описаны пользователи, выделены их предпочтения и потребности. Анализ бизнес-процессов (AS-IS и TO-BE) позволили сформировать видение разрабатываемой системы. Моделирование бизнес-процесса TO-BE в совокупности с требованиями позволили сформировать требования к информационной системе.

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

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

2. Проектирование приложения

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

2.1 Проектирование базы данных

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

Описание данных.

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

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

Процессы и необходимые для выполнения процессов данные, представлены ниже:

1. Настройка мобильного приложения.

a. Регулярность проверки.

2. Подписки на страницы определенных образовательных программ.

a. Кампус.

b. Академическая степень.

c. Наименование факультета.

d. Наименование образовательной программы.

e. Ссылка на образовательную программу.

f. Раздел.

g. Рубрика.

3. Мониторинг сайта и отображение информации.

a. Ссылка на статью.

b. Дата выхода статьи.

c. Наименование статьи.

d. Статус.

Приведение данных к первой нормальной форме.

Для того, чтобы отношение находилось в 1НФ, значения всех атрибутов должны быть атомарны. Данные представлены ниже:

· кампус;

· академическая степень;

· наименование факультета;

· наименование образовательной программы;

· регулярность проверки;

· ссылка на образовательную программу;

· раздел;

· рубрика;

· ссылка на статью;

· дата выхода статьи;

· наименование статьи;

· статус;

Все представленные значения являются атомарными, следовательно, отношение находится в первой нормальной форме.

Приведение данных ко второй нормальной форме.

Чтобы отношение находилось во второй нормальной форме, необходимо, чтобы оно находилось в 1НФ, и все не ключевые атрибуты функционально полно зависели от потенциального ключа.

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

В отношении «Настройки», имеется лишь один атрибут. Добавим к нему ключ «ID», который не будет составным. Таким образом, отношение «Настройки» находится во второй нормальной форме.

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

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

Отношения представлены в таблице 2.1. Первичные ключи выделены курсивом с подчеркиванием.

Таблица 2.1. Описание данных для настройки приложения

Отношение «Настройки»	Отношение «Подписки»	Отношение «Мониторинг»
ID	ID Образовательной программы	ID статьи
Регулярность проверки.	Кампус	Ссылка на статью
	Академическая степень	Дата выхода статьи
	Наименование факультета	Наименование статьи
	Наименование образовательной программы	Статус
	Ссылка на образовательную программу
	Раздел
	Рубрика

Приведение данных к третьей нормальной форме.

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

В отношении «Настройки» отсутствуют транзитивные функциональные зависимости. Можно считать, что отношение находится в третьей нормальной форме.

В отношении «Подписки» отслеживаются следующие транзитивные функциональные зависимости:

1. ID образовательной программы - ID кампуса, ID кампуса - кампус.

2. ID образовательной программы - ID академической степени, ID академической степени - академическая степень.

3. ID образовательной программы - ID факультета, ID факультета - факультет.

4. ID образовательной программы - ID раздела, ID раздела - раздел.

5. ID образовательной программы - ID рубрики, ID рубрики - рубрика.

Для избавления от этих зависимостей, декомпозируем отношение «Подписки», получив отношения «Кампус», «Академическая степень», «Факультет», «Образовательная программа», «Подписки», «Разделы», «Рубрики». Вид этих отношений представлен в табл.2.1. - 2.2. Ключевые поля выделены курсивом с подчеркиванием.

Таблица 2.2. Результат декомпозиции отношения «Подписки». Часть 1.

Отношение «Кампус»	Отношение «Академическая степень»	Отношение «Факультет»	Отношение «Образовательная программа»
ID кампуса	ID академической степени	ID факультета	ID образовательной программы
Кампус	Академическая степень	ID академической степени	ID факультета
		ID кампуса	Наименование образовательной программы
		Факультет	Ссылка на образовательную программу

Таблица 2.3. Результат декомпозиции отношения «Подписки». Часть 2.

Отношение «Подписки»	Отношение «Разделы»	Отношение «Рубрики»
ID образовательной программы	ID раздела	ID рубрики
ID раздела	Раздел	Рубрика
ID рубрики

Отношение «Факультет» связано с отношением «Образовательная программа» связью 1:М по атрибуту «ID факультета».

Отношение «Академическая степень» связано с отношением «Факультет» связью 1:М по атрибуту «ID академической степени».

Отношение «Кампус» связано с отношением «Факультет» связью 1:М по атрибуту «ID кампуса».

Отношение «Разделы» связано с отношением «Подписки» связью 1:М по атрибуту «ID раздела».

Отношение «Рубрики» связано с отношением «Подписки» связью 1:М по атрибуту «ID рубрики».

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

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

Рисунок 2.1. ER-диаграмма базы данных

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

2.2 Прототипирование страниц мобильного приложения

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

Выбор средства прототипирования.

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

Сервис является платным, стоимость месячной подписки составляет 29 долларов для одного пользователя. Однако, предоставляется возможность пробного использования на 15 дней. Этой возможностью было решено воспользоваться.

Прототипирование главной страницы приложения.

В связи с тем, что приложение является лишь подобием новостного приложения, главной целью которого является оповещение пользователей об изменениях на сайте той или иной образовательной программы НИУ ВШЭ, было принято решение не перегружать интерфейс обилием анимационных эффектов. Интерфейс главной страницы, а также остальных страниц приложения, выдержан в фирменных цветах Высшей Школы Экономики, для этого использовался брендбук (руководство по использованию фирменного стиля), представленный на сайте НИУ ВШЭ. Основной цвет имеет кодировку #003399 и используется в заголовках страниц мобильного приложения. Остальная область имеет белый цвет. Текст в заголовках белого цвета, в основной области - черного. В соответствии с руководством по использованию фирменного стиля НИУ ВШЭ, основным наборным шрифтом является Myriad Pro. Данный шрифт будет использован на всех страницах мобильного приложения. Вид главной страницы мобильного приложения представлен на риc. 2.2.



Рисунок 2.2. Главная форма приложения

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

Прототипирование страницы настроек.

Вид страницы настроек мобильного приложения представлен на рис. 2.3.

Рисунок 2.3. Форма настроек приложения

Страница настроек состоит из заголовка и двух областей, предназначенных для настройки приложения. Первая область «Частота обновления» представлена элементом «SeekBar», который является наследником класса «ProgressBar» и представляет из себя обычный слайдер, значение которого пользователь может менять, передвигая пальцем ползунок на экране.

Вторая область - подписки пользователя. В нем списком отражаются образовательные программы, на которые подписан пользователь с указанием кампуса, например, подписка пользователя на образовательную программу бизнес-информатика в Пермском кампусе НИУ ВШЭ будет выглядеть в этом списке, как «Бизнес-информатика. Бак. Пермь». При нажатии на пункт списка, пользователь будет перенаправляться на страницу настройки конкретной подписки, где сможет изменить свои предпочтения, связанные с разделом сайта или рубриками, на которые подписан пользователь.

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

Прототипирование страницы добавления подписок.

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

Первое поле выбора - элемент «Scroll Table», представляющий из себя полоску с элементами для выбора, которые передвигаются по горизонтали. Данный элемент предназначен для выбора кампуса, образовательная программа которого нам интересна.

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

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

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

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

Вид страницы подписок представлен на рис. 2.4.

Рисунок 2.4. Форма добавления подписок

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

Прототипирование страницы настройки подписок.

Вид страницы настройки конкретной подписки представлен на рис. 2.5.

Рисунок 2.5. Форма настройки конкретной подписки

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

Прототипирование страницы, содержащей текст статьи.

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

Ниже идет сама статья, сохраняя оригинальную разметку, представленную на сайте университета. Вид экранной формы представлен на рис. 2.6.

Рисунок 2.6. Форма, содержащая статью

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

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

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

3. Разработка мобильного приложения

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

3.1 Разработка главного экрана приложения

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

Функционал формы обеспечивает выполнение следующих функций:

1. Создание базы данных (при первом запуске приложения).

2. Создание таблиц базы данных (при первом запуске приложения).

3. Заполнение базы первичными данными (при первом запуске приложения).

4. Выборка данных о статьях.

5. Форматирование данных о статьях в вид, удобный для пользователя.

6. Вывод списка статей.

7. Обработка действий пользователя:

a. Нажатие кнопки «Настройки».

b. Нажатие на определенную статью.

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

Рисунок 3.1. Пример запроса на языке SQL

Снимок главного экрана приложения представлен на рис. 3.2.

Рисунок 3.2. Главная экранная форма приложения

3.2 Разработка экрана настройки приложения

На экране настройки расположены три основных элемента. Первый элемент - SeekBar. Элемент отвечает за настройку частоты мониторинга статей на страницах образовательных программ НИУ ВШЭ (в часах). Минимальное значение, которое может установить пользователь - 0 (в случае, если пользователь временно не хочет получать уведомления о новых публикациях), максимальное значение - 168, что равняется одной неделе.

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

Третий элемент - FloatingActionButton. Элемент имеет вид круглой кнопки со знаком плюс и расположен в правом нижнем углу экранной формы.

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

Снимок экрана настроек приложения представлен на рис. 3.3.

Рисунок 3.3. Снимок экрана настроек

3.3 Разработка экрана добавления подписки

Экран подписки включает в себя три элемента Spinner, расположенных друг за другом, а также элемента ListView, расположенного после элементов Spinner.

При открытии формы, в элементы Spinner с помощью SQL подгружаются значения из базы данных. Меняя значения одного из них, пользователь может влиять на значения в других. Например, выбрав значение кампуса «Пермь», в последнем элементе пользователь увидит названия тех факультетов, которые есть в НИУ ВШЭ-Пермь. Также, выбрав кампус и факультет, но изменив академическую ступень со значения «Бакалавриат» на значение «Магистратура», пользователь изменит значения элементов ListView, в который подгружаются образовательные программы в соответствии с данными, установленными в элементах Spinner.

Снимок экранной формы добавления подписки представлен на рис. 3.4.

Рисунок 3.4. Форма добавления подписок

3.4 Разработка экрана пользовательской настройки подписки

Каждой статье, публикуемой на сайте НИУ ВШЭ, присваивается конкретная рубрика, которой она соответствует по смыслу. Экран пользовательской настройки подписки позволяет пользователю выбрать, на какие разделы и рубрики он хочет быть подписан.

Экран состоит из двух блоков элементов CheckBox и одного элемента Button. В первом блоке находятся два элемента CheckBox. В этом блоке пользователь делает выбор, на какие разделы он хочет быть подписан (объявления и новости). В случае, если не выбрано ни одной новостной рубрики, пользователь может сделать выбор сразу всех рубрик, установив CheckBox новостей в положение true.

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

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

Экран пользовательской настройки подписки представлен на рис. 3.5.

Рисунок 3.5. Экран пользовательской настройки подписки

3.5 Разработка экрана, содержащего статью

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

Для реализации данной функции, в документе AndroidManifest.xml были выданы разрешения для доступа в интернет. Этот документ содержит всю важнейшую информацию, которая требуется системе Android для нормального функционирования приложения на устройстве.

Снимок экранной формы и метод, отвечающий за перенос статьи в приложение, представлены на рис. 3.6 и рис. 3.7 соответственно.

Рисунок 3.6. Экранная форма, содержащая статью

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

Рисунок 3.7. Метод, отвечающий за перенос статьи в приложение

3.6 Разработка экрана для отображения web-версии страницы

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

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



Рисунок 3.8. Экранная форма для отображения web-версии страницы

3.7 Тестирование мобильного приложения

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

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

2. Попытка чтения статей некоторых образовательных программ НИУ ВШЭ (Москва) приводила к ошибке программы в связи с тем, что ссылки имели вид «/bi/news/195401712.html» вместо полной ссылки «https://perm.hse.ru/bi/news/195401712.html».

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

4. В связи с несовершенством алгоритма сканирования страниц, существовала проблема дублирования данных в этом процессе. Ошибка была исправлена.

В процессе тестирования, была протестирована способность программы сканировать образовательные программы, имеющиеся в НИУ ВШЭ, а именно 177 образовательных программ на 20 факультетах в 4 кампусах. Программа отсканировала и перенесла в программу 6670 новостных статей и объявлений.

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

Приложение готово к использованию.

Заключение

информационный веб мобильный сайт

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

...