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

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

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

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

Описание

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

1) Top-to-Down - сначала продумываются сущности, их количество, их взаимодействие. И только потом, постепенно делается переход к реализации этих сущностей, к коду и низкоуровневым вещам.

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

Обычно, вторую методику принято использовать в разработке встроенных систем, где большинство кода работает на очень низком уровне. И в большинстве случаев, именно от него (от реализации), зависит вся архитектура приложения. Для серверной части системы информирования жителей об авариях на системах ЖКХ, была выбрана методика Top-To-Down и перед началом разработки была проделана работа по выделению основных сущностей и понятий. Схема взаимодействия объектов реализации представлена на Рисунке 3.

Рисунок 3 - Архитектура серверной части

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

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

Балансировщик

В качестве балансера был выбран Nginx, как самое популярное и зарекомендовавшее себя решение. Nginx используется более чем в 479 миллионов сайтов, по данным Netcraft на декабрь 2019 года.

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

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

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

Серверная часть

Серверная часть представляет из себя сервер, написанный на языке Python, с использованием фреймворка FastApi и поддерживающий общение с пользовательским интерфейсом по протоколу REST API.

Однако, перед тем как писать обработчики для POST, GET и прочих запросов, нужно определиться с тем, над какими объектами мы собираемся работать. Единственной сущностью, которой оперирует сервис, является событие или заявка (event). Для того, чтобы иметь возможность сохранять заявки в базу данных, а также упростить работу с ними из кода, нужно было создать модель данных.

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

· ID - уникальный идентификатор события

· Created_at - время, когда событие было создано

· Description - описание, не длиннее, чем 250 символов

· Type - тип события: газ, вода, электричество и пр.

· Priority - приоритет, который выставляется оператором, при обработке заявления. Может быть: очень низким, низким, средним, высоким и критическим.

· Status - в обработке, отложена, ведутся работы, выполняется оценка, выполнена, отклонена

· Deadline - крайний срок выполнения заявки (проставляется оператором)

· Start time - когда фактически начались работа

· Resolved_at - когда фактически закончились работы

· User id - идентификатор пользователя, создавшего заявку

· Position - координаты происшествия

· Rating - какое количество людей пострадало из-за происшествия

· Is system - является ли отключение плановым или нет

· Rejected reason - причина отклонения заявки. В случае отклонения заявки, это поле обязательно к заполнению

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

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

Рисунок 4 - Листинг POST-обработчика для событий

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

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

i. Получить все заявки

ii. Получить только актуальные (не закрытые)

iii. Получить только ждущие подтверждения

По умолчанию, возвращаются только актуальные заявки. Если клиент хочет получить заявки только одного конкретного пользователя, то есть возможность передать пользовательский ID, то по нему также будут доступны опции, перечисленные выше. Также, на стороне серверной части реализована функция пагинации. Пагинация дает возможность запрашивать не все заявки сразу, а постранично. С учетом масштабирования проекта и длительного его существования, их может быть больше миллиона. Сначала, например, первые 20, затем следующие 20 и так далее (Рис. 5). Клиент может передать на серверную часть интервал заявок, которые он хочет запросить. Однако, есть ограничения на количество одновременно запрашиваемых заявок. Этот параметр хранится в конфигурационном файле и может быть изменен по желанию локального администратора. Пагинация также работает с упомянутым ранее функционалом.

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

Рисунок 5 - Листинг GET-обработчика для событий

Последний пункт в работе с заявкой - это возможность ее изменить. Если клиенту необходимо сменить статус заявки или снизить приоритет, для этого он может воспользоваться PATCH запросом (Рис. 6). При этом, будут произведены проверки на ID заявки и пользователя. Для упрощения работы оператора и повышения производительности сервиса в целом, реализовано изменение нескольких полей заявки за один запрос. Также, если оператор будет менять статус заявления на "отклонено", но забудет указать причину, то такой запрос просто не пройдет, а пользовательскому интерфейсу вернется ошибка.

Рисунок 6 - Листинг PATСH-обработчика для событий

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

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

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

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

· Top-Down Integration (Рис. 10), предполагает, что разработка начинается с написания основных абстракций, а затем, постепенно двигаясь сверху вниз, команда постепенно углубляется в детали реализации. Основной плюс - главная логика работы программы будет протестирована более внимательно на более ранних этапах разработки. Кроме того, такая модель позволяет начать писать код раньше, чем будут до конца выяснены низкоуровневые детали реализации. Однако, есть и свои минусы. Например, если архитектура несовершенна или имеются проблемы с производительностью, все это станет ясно только на самых поздних этапах разработки, когда все низкоуровневые вещи будут дописаны.

Рисунок 10 - Top-Down Integration

· Bottom-Up Integration (Рис. 11) - это подход, при которым программисты начинают разработку системы с реализации наиболее мелких ее частей и постепенно, двигаетесь вверх, объединяют их в целую систему. К сожалению, у такого подхода есть свои недостатки. Нужно завершить разработку архитектуры всего приложения до начала написания кода. А также, если имеются какие-то проблемы с верхнеуровневым дизайном - они будут выявлены только на самом последнем этапе разработки.

Рисунок 11 - Bottom-Up Integration

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

Рисунок 12 - Sandwich Integration

· Risk-Oriented Integration (Рис. 13) пытается также как и Sandwich Integration минимизировать недостатки двух предыдущих методов, но делает это немного другим способом. При данном подходе, программисты оставляют реализацию среднего уровня абстракций на последний момент, но начинают реализацию классов высокоуровневых и низкоуровневых абстракций в зависимости от сложности их написания. То есть, самые сложные классы реализовываются в первую очередь, а самые простые в последнюю очередь.

Рисунок 13 - Risk-Oriented Integration

· T-Shaped Integration (Рис. 14) - это подход, при котором выбирается какая-то одна функциональность, чтобы проверить гипотезы об производительности системы, и реализуется сверху вниз. Это позволяет на ранних стадиях разработки понять какие идеи дизайна приложения были верны, а какие оказались не самыми удачными.

Рисунок 14 - T-Shaped Integration

· Feature-oriented Integration (Рис. 15) обязывает разделить весь проект на отдельные фичи - функциональности и интегрировать их в общий проект по одной. У данной стратегии есть три основных плюса:

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

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

iii) Этот подход очень хорошо ложится на принцип Объектно-ориентированного программирования, так как каждая функциональность здесь предстает как отдельная иерархия классов.

Рисунок 15 - Feature-oriented Integration

Feature-oriented Integration стратегия разработки и интегрирования была выбрана для создания сервиса. Например, необходим был функционал отображения информации об авариях на карте происшествий, как у оператора в Едином Диспетчерском Центре, так и у обычных пользователей на экранах мобильных телефонов. Следуя данной стратегии, отдельная команда разработчиков сначала разработали интерфейс для отображения таких происшествий для телефона и веб-интерфейса оператора, а затем, данная функциональность была реализована на серверной стороне (Рис. 16). Таким образом, спустя одну такую итерацию, сервис уже имел ограниченный, но в тоже время, работающий функционал. С использованием Feature-oriented Integration подхода и был написан весь сервис для информирования граждан об авариях.

Рисунок 16 - отображение заявок

4. Тестирование программного продукта

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

Основываясь на книге Rapid Development (McConnell, 1996) можно сделать вывод, что основная польза проекту заключается в том, что команда видит, что проект собирается, а тесты проходят, что положительно влияет на их продуктивность. Кроме того, в случае неудачной сборки можно будет установить, в какой именно момент времени был добавлен код, приведший к ошибке. Также, автор рекоммендует ввести систему штрафов за поломанный билд.

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

Пример работы сборочной линии на Рисунке 17.

Рисунок 17 - Пример работы сборочной линии

Рисунок 18 - Конфигурационный файл сборочной линии

Разворачивание решения на сервере

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

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

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

Второй контейнер необходим для базы данных.

Третий контейнер - это балансер с nginx. Здесь тоже все просто - указываем директорию для хранения кэша.

И далее следует самый ответственный момент - написание docker-compose файла. Docker-compose файл содержит имена контейнеров, которые он должен запустить и пути к их docker файлам. Тут же прописываются правила перезапуска контейнера, в случае возникновения ошибок. Прописываются порты, по которым будут доступны база данных и nginx. И теперь после того, как написаны предыдущие файлы, мы можем запустить сервис, введя одну команду в консоль: docker-compose up. И теперь приложение доступно по spacehub.su/api. Конкретно по этому адресу будет доступен swagger с описанием всех доступных запросов.

Результаты

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

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

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

a. Получение списка заявлений с фильтром по их актуальности.

b. Получение одного происшествия по его уникальному ID.

c. Создание события. Если такое событие уже существует (анализ проводится на основе географической близости событий), то у него автоматически увеличивается рейтинг заинтересованности граждан в его решении.

d. Редактирование заявления, есть возможность обновить все поля за один запрос.

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

Кроме того, была решена проблема разворачивания решения на сервере, посредством использования утилиты docker-compose. Были написаны функциональные тесты, с покрытием кода в 82%, а также настроена сборочная линия на платформе gitlab (Continuous Integration), не позволяющая вносить изменения в код, если какой-то из тестов завершился с ошибками.

Дальнейшее развитие

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

Список литературы