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

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

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

«Национальный исследовательский университет

«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

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

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

Паршаков Александр Эдуардович

Пермь, 2020 год



Аннотация

Выпускная квалификационная работа содержит исследование на тему «Разработка мобильного приложения для модели умного города». Прототип приложения был создан с помощью инструмента InVision. Приложение было реализовано для операционной системы iOS.

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

Данная работа содержит 63 страницы основного текста формата А4. Основной текст включает в себя введение, 3 главы (анализ, проектирование и реализация) и заключение. Исследование также содержит 48 иллюстраций и 3 приложения (техническое задание, описание прецедентов и тестирование).

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

Вторая глава состоит из 3 параграфов: алгоритм использования приложения, проектирование приложения и проектирование интерфейса.

Третья глава состоит из 6 параграфов: реализация базы данных, реализация API, интеграция модели данных, реализация работы с сетью, реализация интерфейса и тестирование.

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

Библиографический список содержит 23 источника.



Введение

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

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

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

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

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

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

Объект исследования - предоставление информации об объектах умного города. Предмет исследования - средства предоставления информации об объектах умного города.

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

На основе цели исследования были поставлены следующие задачи:

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

Изучить руководство по дизайну iOS-приложений (Apple Human Interface Guidelines [13]).

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

Реализовать приложение на основе созданного прототипа.

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



1. Анализ предметной области iOS-приложения для умного города

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

Анализ понятия «умный город»

Прежде всего, крайне важно определение суть понятия умного города. Существует множество определений, далее будут приведены некоторые из них. Например, в соответствии с [11], умный город определяется как город оборудованный, взаимосвязанный и интеллектуальный. Также [16] отмечает, что умными городами принято называть те города, которые используют как можно больше появляющихся возможностей по наращиванию объёма ИКТ-инноваций.

В соответствии с [3], существует 6 основных измерений, в который можно рассматривать умный город:

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

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

Smart environment. Поддержка городами дружелюбных к окружающей среде строений, энергии и городского планирования.

Smart people. Предоставление умными городами возможности для образования, создание сплочённого общества и поощрение творческого подхода к вещам.

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

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

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

Выявление типовых примеров использования информационных ресурсов умного города

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

Медицина и здравоохранение (онлайн-запись к врачу, онлайн-хранение документов, напоминание о приёмах, отслеживание показателей здоровья и в режиме онлайн отправка их лечащему врачу и др.).

Социальная сфера (семья, друзья и родственники).

Образование (сюда же можно отнести работу, так как человек в «умном городе» стремится к самообразованию и на работе тоже).

Развлечения (кино, театры, музеи, рестораны и так далее).

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

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

Окружающая среда (с точки зрения экологии и защиты планеты).

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

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

В соответствии с [12], целью городов, развивающих и использующих умный туризм, является фокусировка на персональных нуждах туриста и их удовлетворение. Это должно достигаться за счёт слияния ИКТ с бытовой культурой, что, в свою очередь, обуславливает тот факт, что культура - это важная часть умных городов.

Однако, всегда важно уметь определять возможные способы интеграции технологий умного туризма в будущие умные города. Важнейшим шагом к достижению этой цели может быть предоставление широкого доступа к информации, и, в соответствии с [23], этого можно достигнуть, если предоставлять всем гражданам неограниченный доступ к данным через публично-контролируемую платформу. Вдобавок к этому, не менее важно помнить о том, что некоторое число граждан все ещё может быть не готово к принятию инновационных перемен в силу технологической неграмотности. Как правило, такие граждане вынуждены пытаться изучать быстроменяющиеся технологии собственными силами [14], что формирует строгую необходимость в реализации эффективных, но вместе с тем простых в использовании технологий. Также, умным городам необходимо обеспечивать интеллектуальность путём установки подходящих для туризма прикладных элементов [6]. Это может увеличить охват «умности» городов, а значит может и способствовать повышению мотивацию людей к изучению новых, лучших способов взаимодействия с городом.

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

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

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

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

Ограничения информационной модели

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

Сфера развлечений

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

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

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

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

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

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

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

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

Ниже отображена таблица с возможными объектами отслеживания и чрезвычайными ситуациями, соответствующими им:

Таблица 1.1 - Список отслеживаемых объектов в сфере безопасности

Объект	Чрезвычайная ситуация
Электрическое напряжение	Аварийное отключение электричества
Уровень влажности воздуха	Затопление помещения, повышенная влажность воздуха
Наличие освещения	Перегорание ламп
Состояние входной двери	Незаконное проникновение
Смещения и амплитуда	Землетрясение
Концентрация вредных веществ	Взрыв/отравление

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

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

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

2. Описание процесса получения данных об объекте умного города

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

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

Поиск инфраструктурного объекта, который представляет интерес.

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

Ознакомление с информацией об объекте.

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

Выбор инструментальных средств

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

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

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

Таким образом, в качестве целевой операционной системы будет выступать iOS, из чего следует, что в качестве языкового инструмента разработки приложений могут выступать два языка: Objective-C и Swift.

Поскольку язык Swift активно развивается компанией Apple и до 2.6 быстрее Objective-C [20], было принято решение при разработке использовать именно его.

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

В качестве заключительного этапа при выборе инструментальных средств важно выбрать инструмент создания графического интерфейса. При написании мобильного приложения в Xcode на языке Swift существует два возможных варианта: конструктор интерфейса Storyboard и визуальный фреймворк SwiftUI. Приложение подразумевает поддержку iOS начиная от 10 версии, а поскольку SwiftUI требует в качестве минимальной версии системы iOS 13, был сделан выбор в пользу Storyboard.

Далее, поскольку постоянное обращение к API за одними и теми же данными не является позволительной практикой (в силу избыточного использования ресурсов пользователя), необходимо выбрать инструмент для локального хранения таких данных. В качестве основных баз данных для локального хранения выступают CoreData (созданный компанией Apple) и Realm, созданный Apache. В силу наличия более удобного для использования API было принято решение использовать Realm.

Требования к iOS-приложению для умного города

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

Функциональные требования

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

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

Предоставлять пользователю возможность просмотреть данные о конкретном объекте.

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

Предоставлять пользователю возможность просмотреть данные об объекте с соответствующей меткой.

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

Нефункциональные требования

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

Приложение должно использоваться на смартфонах.

Мобильное приложение должно работать на операционной системе iOS. В качестве минимальной поддерживаемой версии системы является iOS 10.

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

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

На основе выстроенных требований было составлено техническое задание, которое представлено в Приложении А.

Распределение требований по прецедентам

Для необходимого понимания того, как должно будет функционировать приложение, была построена диаграмма прецедентов (см. рис. 1.1):

Рисунок 1.1 - Диаграмма прецедентов

После повторного анализа диаграммы был составлен список прецедентов, который представлен в табл. 1.2:



Таблица 1.2 - Список прецедентов

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

Подробный анализ прецедентов представлен в приложении Б.

Проектирование iOS-приложения для умного города

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

Алгоритм использования приложения

Просмотр данных об объектах

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

Переход к вкладке с нужной категорией объектов.

Данный этап подразумевает открытие меню и выбор категории объектов с нужными названием и просмотр списка объектов.

Выбор нужного объекта.

Просмотр информации.

Сканирование метки

Исходя из технического задания, процесс будет состоять из 3 этапов:

Поиск места (здания/строения), которое представляет интерес.

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

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

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

Ознакомление с информацией о здании (возможные мероприятия/развлечения/историческая справка/данные безопасности).

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

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

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

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

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

Ниже представлены таблицы с описанием полей, их предполагаемых типов с комментарием для поля, а также с наиболее релевантным элементом интерфейса при реализации (см. табл. 2.1-2.6).

Таблица 2.1 - Описание полей для информационной модели «Здание»

Наименование поля	Тип поля	Элемент интерфейса	Комментарий
ID	Int	Отсутствует	Уникальный идентификатор, для пользователя не выводится в силу отсутствия необходимости
Name	String	UILabel	Название ресторана
Description	String	UILabel	Описание ресторана
HistoricalAccount	String	UILabel	Описание ресторана
Picture	Image	UIImageView	Фотография ресторана
Latitude	Decimal	UILabel	Широта
Longitude	Decimal	UILabel	Долгота
Country	String	UILabel	Страна
Region/Province/ Neighborhood	String	UILabel	Регион, провинция или район
City	String	UILabel	Город
Street	String	UILabel	Улица
House/Building	String	UILabel	Дом/строение/корпус
Organizations	List<Organization>?	UICollectionView	Список организаций в здании

Таблица 2.2 - Описание полей для информационной модели «Ресторан»

Наименование поля	Тип поля	Элемент интерфейса	Комментарий
ID	Int	Отсутствует	Уникальный идентификатор, для пользователя не выводится в силу отсутствия необходимости
Name	String	UILabel	Название ресторана
Description	String	UILabel	Описание ресторана
Picture	Image	UIImageView	Фотография ресторана
Rating	Double	UIStackView	Рейтинг, отображается в виде ряда из пяти звёзд
AverageCheck	Int	UILabel	Берём целочисленное значение, поскольку для пользователя не имеют значения цифры после запятой
NumberOfEmptyTables	Int	UILabel	Количество свободных столиков
FamousCooks	List<Person>?	UICollectionView (horizontal)	Cписок со знаменитыми поварами, которые могут привлечь человека. Список может быть пустым, а потому заключён в опциональный тип. Для экономии места и снижения когнитивной нагрузки на пользователя список будет отображаться горизонтально
FanciestDishes	List<Dish>?	UICollectionView (horizontal)	Список с самыми необычными блюдами. Список может быть пустым, а потому заключён в опциональный тип. Для экономии места и снижения когнитивной нагрузки на пользователя список будет отображаться горизонтально
MostPopularDishes	List<Dish>?	UICollectionView (horizontal)	Опциональный список с самыми популярными блюдами
Website	String	UIButton	Сайт ресторана, переход на сайт осуществляется через встроенный браузер Safari посредством нажатия на кнопку

Таблица 2.3 - Описание полей для информационной модели «Кинотеатр»

Наименование поля	Тип поля	Элемент интерфейса	Комментарий
ID	Int	Отсутствует	Уникальный идентификатор, для пользователя не выводится в силу отсутствия необходимости
Name	String	UILabel	Название кинотеатра
Description	String	UILabel	Описание кинотеатра
Picture	Image	UIImageView	Фотография кинотеатра
Website	String	UIButton	Сайт кинотеатра, переход на сайт осуществляется через встроенный браузер Safari посредством нажатия на кнопку
ComfortabilityRating	Double	UIStackView	Рейтинг, отображается в виде ряда из пяти звёзд
Movies	List<Movie>	UICollectionView (horizontal)	Список фильмов, находящихся в прокате. Для экономии места и снижения когнитивной нагрузки на пользователя список будет отображаться горизонтально

Таблица 2.4 - Описание полей для информационной модели «Кино»

Наименование поля	Тип поля	Элемент интерфейса	Комментарий
ID	Int	Отсутствует	Уникальный идентификатор, для пользователя не выводится в силу отсутствия необходимости
Name	String	UILabel	Название фильма
Description	String	UILabel	Описание фильма
Picture	Image	UIImageView	Постер фильма
Rating	Double	UILabel	Рейтинг фильма
ReleaseDate	Date	UILabel	Дата начала проката
EndDate	Date	UILabel	Дата окончания проката
BoxOffice	Int?	UILabel	Кассовые сборы, опционально
Showings	List<Showing>	UITableView	Сеансы

Таблица 2.5 - Описание полей для информационной модели «Музей»

Наименование поля	Тип поля	Элемент интерфейса	Комментарий
ID	Int	Отсутствует	Уникальный идентификатор, для пользователя не выводится в силу отсутствия необходимости
Name	String	UILabel	Название музея
Description	String	UILabel	Описание музея
Picture	Image	UIImageView	Фотография музея
Website	String	UIButton	Сайт музея, переход на сайт осуществляется через встроенный браузер Safari посредством нажатия на кнопку
Exhibitions	List<Exhibition>	UICollectionView (horizontal)	Список ближайших выставок. Для экономии места и снижения когнитивной нагрузки на пользователя список будет отображаться горизонтально

Таблица 2.6 - Описание полей для информационной модели «Выставка»

Наименование поля	Тип поля	Элемент интерфейса	Комментарий
ID	Int	Отсутствует	Уникальный идентификатор, для пользователя не выводится в силу отсутствия необходимости
Name	String	UILabel	Название выставки
Description	String	UILabel	Описание выставки
Picture	Image	UIImageView	Постер выставки
StartDate	Date	UILabel	Дата начала выставки
EndDate	Date	UILabel	Дата окончания выставки
Showings	List<Showing>	UITableView	Показы выставки

Таблица 2.7 - Описание полей для информационной модели «Безопасность»

Наименование поля	Тип поля	Элемент интерфейса	Комментарий
ID	int	Отсутствует	Уникальный идентификатор
Latitude	Decimal	UILabel	Широта
Longitude	Decimal	UILabel	Долгота
Country	String	UILabel	Страна
Region/Province/ Neighborhood	String	UILabel	Регион, провинция или район
City	String	UILabel	Город
Street	String	UILabel	Улица
House/Building	String	UILabel	Дом/строение/корпус
Sensors	List<Sensor>?	UITableView	Опционально, может быть не у всех зданий
Indicators	List<Indicator>?		От значения показателей зависит, включать ли сигнализацию и вызывать ли экстренные службы.
LegalAct	Document	Отсутствует	Нормативно-правовые акты нужны для отображения нормы значения показателей, измеряемых датчиками. Хранится в документно-ориентированной базе данных (например, mongoDB).

Добавление новых объектов

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

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

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

Диаграмма потоков данных

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

Рисунок 2.1 - Диаграмма потоков данных для БП «Получение данных о здании»

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

Также важно заметить, что в качестве передаваемых клиенту данных будет выступать объект передачи данных (Data Transfer Object, DTO). Такой объект представляет собой исключительно набор данных, необходимых клиенту/серверу для выполнения процесса конкретного представления, что помогает снизить нагрузку на сеть за счёт отсутствия в объекте передачи неиспользуемых в конкретном представлении полей.

Диаграммы последовательности

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

Рисунок 2.2 - Диаграмма последовательности для прецедента «Сканировать метку»

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

Ниже представлена диаграмма последовательности для прецедента «Сканировать метку» (см. рис. 2.2):

Ниже представлена диаграмма последовательности для прецедента «Просмотреть информацию об объекте с соответствующей меткой» (см. рис. 2.3):



Рисунок 2.3 - Диаграмма последовательности для прецедента «Просмотреть информацию об объекте с соответствующей меткой»

*

Рисунок 2.4 - Диаграмма последовательности для прецедента «Просмотреть список объектов умного города»

Ниже представлена диаграмма последовательности для прецедента «Просмотреть список объектов» (см. рис. 2.4):

Ниже представлена диаграмма последовательности для прецедента «Просмотреть информацию об объекте» (см. рис. 2.5):



Рисунок 2.5 - Диаграмма последовательности для прецедента «Просмотреть информацию об объекте»

Ниже представлена диаграмма последовательности для прецедента «Просмотреть информацию о датчиках» (см. рис. 2.6):

Рисунок 2.6 - Диаграмма последовательности для прецедента «Просмотреть информацию о датчиках»

Диаграмма классов

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



Рисунок 2.5 - Диаграмма бизнес-классов

Проектирование интерфейса

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

Приложение будет выстраиваться с помощью паттерна MVC [9], что обусловлено его удобством и частой применимостью, включая проекты с относительно небольшим объёмом программного кода.

Изучение и выделение основных принципов построения iOS-интерфейса

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

Цветовая палитра элементов

На момент написания работы в iOS 13 присутствуют две системные темы: светлая и тёмная, поэтому в качестве основных цветовых палитр будут использованы стандартные цвета (белый и черный/тёмно-серый), поскольку они обладают нейтральным оттенком при отображении рядов данных и соотносятся с темой самой системы.

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

Также стоит отметить, что для акцентирования внимания пользователя кнопки, которые должны быть нажаты по наиболее вероятному сценарию, должны быть выделены акцентирующим цветом (например, градиент). Это позволит пользователю совершать подразумеваемые семантикой приложения действия на некоторое время быстрее, поскольку визуально выделяемая кнопка позволяет ускорить поиск нужного действия [22].

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

Оповещения

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

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

Использование анимации

Использование анимации должно создавать плавность взаимодействия для пользователя, а также создавать эффект «реальности» элементов интерфейса [4]. Чтобы достичь этого, необходимо использовать анимации в умеренном количестве и только с элементами, которые ожидают коммуникации от пользователя. Умеренное использование анимации позволит как сконцентрировать внимание пользователя на нужных элементах интерфейса, так и сохранить уровень его вовлеченности в приложение, не отвлекая излишним движением интерфейса [13].

4. Разумное использование пространства на экранах

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

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

Выбор типа меню

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

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

Рисунок 2.6 - Макет меню приложения

Построение прототипа приложения

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

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

Сценарий сканирования

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

Непосредственно сканирование может быть начато при нажатии на кнопку в верхней правой части главного экрана (см. рис. 2.7):

Рисунок 2.7 - Макет главного меню

Далее, при нажатии на кнопку «Сканировать» происходит переход непосредственно к экрану сканирования (см. рис. 2.8), где пользователю необходимо поместить метку (QR-код) в сканируемую область экрана. После успешного сканирования пользователю показывается сообщение с адресом найденного здания (см. рис. 2.9).

Рисунок 2.8 - Макет экрана сканирования, 2.9 - Макет экрана успешного сканирования

Если пользователь желает просканировать снова, он нажимает кнопку «Отмена». Если все верно, и пользователь желает просмотреть подробную информацию о здании и его организациях, он нажимает кнопку «Продолжить», после чего попадает на экран просмотра информации о здании и его организациях (см. рис. 2.10):



Рисунок 2.10 - Макет экрана просмотра информации о здании

На экране просмотра информации об организации типа «Кинотеатр» отображается электронный адрес кинотеатра, его средняя оценка по шкале от 1 до 5, а также список фильмов, находящихся в прокате в данный момент (см. рис. 2.11):



Рисунок 2.11 - Макет экрана просмотра информации о кинотеатре

На экране просмотра информации об организации типа «Ресторан» отображается электронный адрес ресторана, его средняя оценка по шкале от 1 до 5, а также список блюд, имеющихся в ассортименте в данный момент (см. рис. 2.12): информационный анимация интерфейс приложение



Рисунок 2.12 - Макет экрана просмотра информации о ресторане

На экране просмотра информации об организации типа «Музей» отображается электронный адрес музея, его средняя оценка по шкале от 1 до 5, а также список выставок, проходящих в ближайшее время (см. рис. 2.13):



Рисунок 2.13 - Макет экрана просмотра информации о музее

Сценарий просмотра истории сканирований

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



Рисунок 2.14 - Макет экрана просмотра истории сканирований

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

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

Рисунок 2.15 - Макет экрана настроек

Сценарий изменения настроек

Панель настроек выстроена в классическом для iOS стиле, а именно UITableView со статическими ячейками (см. рис. 2.15):

При нажатии на кнопку «Цветовая тема» происходит переход на экран выбора (смены) цветовой темы приложения (см. рис. 2.16):

Рисунок 2.16 - Макет экрана смены цветовой темы

Реализация iOS-приложения для модели умного города

Реализация базы данных

База данных была нормализована, а затем реализована с помощью SQL Server. Конечный вид базы данных принял следующий вид (см. рис. 3.1):

Реализация API

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



Рисунок 3.1 - Схема базы данных

Далее, для возможности взаимодействия базы данных с API база данных была размещена на ресурсе Microsoft Azure (см. рис 3.2):

Рисунок 3.2 - Свойства размещённой базы данных

Поскольку API планируется разрабатываться планомерно, по мере необходимости самого мобильного приложения, было принято решение разместить сервис сразу на Microsoft Azure, после чего обновлять его при всех важных изменениях бизнес-логики.

Ниже можно видеть все свойства размещённого сервиса (см. рис. 3.3):



Рисунок 3.3 - Свойства размещённого сервиса API

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

Генерация модели данных

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

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



Рисунок 3.4 - Архитектура решения API

Выбрав категорию Tables при создании модели данных, автоматически были сгенерированы классы с необходимы свойствами, включая коллекции, основанные на отношениях, выстроенных в базе данных (см. рис. 3.5):

Создание объектов передачи данных

В соответствии с [7], для того, чтобы мобильному приложению передавались только необходимые поля с необходимыми идентификаторами было принято решение создавать объекты передачи данных (DTO - Data Transfer Object).



Рисунок 3.5 - Модель данных в API, созданная с помощью Entity Framework

Пример такого объекта представлен на рисунке 3.6:

Рисунок 3.6 - Модель передачи данных для сущности ArtOrganization

Дополнительно стоит отметить использование библиотеки Newtonsoft.Json, позволяющей изменить наименование полей на нужные. Данная возможность была использована для каждого из объектов передачи данных, поскольку язык Swift подразумевает использование стиля Lower Camel case [21] - в силу этого все первые буквы наименований полей были переведены на нижний регистр.

5. Реализация запросов к базе данных

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

Запрос к данным осуществляется с помощью LINQ-запросов и использованием «быстрой загрузки» (Eager Loading) [15] для всех необходимых коллекций с помощью метода Include(). Также при каждом запросе осуществляется отключение кэширования для более быстрой выгрузки данных с помощью метода AsNoTracking() [1]. Это продемонстрировано на рисунке 3.7:

Рисунок 3.7 - Модель передачи данных для сущности ArtOrganization

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

Создание mock-объектов

Для демонстрационных целей внутри API был создан сервис, предоставляющий коллекции сущностей с уже заполненными полями. Методы данного сервиса вызываются в случае отсутствия данных в базе данных. Так, метод для получения «фиктивного» здания был реализован следующим образом (см. 3.8):

Рисунок 3.8 - Метод получения mock-данных для здания

Пример использования данного метода представлен ниже:

На данном примере видно, что при отсутствии элементов в коллекции происходит возврат значений с помощью Mock-сервиса.

Интеграция модели данных

Для принятия данных внутри мобильного приложения были созданы соответствующие классы (см. рис. 3.9):

Как видно, в соответствии с паттерном MVC, была создана группа файлов Models, которая вобрала в себя необходимые классы (модели).

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

Рисунок 3.9 - Список классов мобильного приложения

Для удобства реализации мобильного приложения были созданы пустые классы для кинотеатра и музея (см. рис. 3.10). Подобные классы были также созданы для кино и выставки соответственно (см. рис. 3.11).

Рисунок 3.10 - Кл...