ФОРМАЛИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПОЛЬЗОВАТЕЛЬСКОГО КРОССПЛАТФОРМЕННОГО МОБИЛЬНОГО ПРИЛОЖЕНИЯ Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.4

ФОРМАЛИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПОЛЬЗОВАТЕЛЬСКОГО КРОССПЛАТФОРМЕННОГО МОБИЛЬНОГО ПРИЛОЖЕНИЯ

В.Н. Черников, С.Л. Подвальный, В.Ф. Барабанов, А.М. Нужный

Воронежский государственный технический университет, г. Воронеж, Россия

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

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

Введение

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

Во время развития проекта команды могут столкнуться со следующими проблемами [1]:

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

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

3. Отсутствие единой документации (кроме Технического задания, далее ТЗ) для всей команды, которая бы позволила нахо-

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

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

1. Первичная документация

Ключевой тезис, лежащий в основе представленной методики:

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

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

© Черников В.Н., Подвальный С.Л., Барабанов В.Ф., Нужный А.М., 2018

экране и управляют его поведением. Бизнес-сценарии также напрямую завязаны на поведение пользовательского интерфейса [2].

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

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

Рис. 1. Циклический процесс разработки

Итак, у проекта обычно выделяют следующие производственные классы задач:

- анализ;

- проектирование и дизайн;

- кодирование;

- тестирование;

- эксплуатация.

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

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

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

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

ТЗ

функциональные и

бизнес-требования

Шрифты

Картинки

Рис. 2. Типовые документы для этапа разработки

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

2. Экраны, данные и логика

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

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

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

2.1. Группировка экранов и сквозное именование

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

Рис. 3. Пользовательские бизнес-сценарии

А X 42

I н 5

7 в К

и ТУ С

1. Account

1.1 "А"

1.2 "X"

1.3 "Г

1.4 "Н"

2. Help

2.1 ... 2.2 ... 2.3 ...

3. Checkout

3.1 ... 3.2 ... 3.3 ...

Названия файлов и структура "от дизайнера"

Названия файлов и структура "для программиста"

Рис. 4. Структурирование дизайна экранов

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

Например, могут получиться следующие разделы:

1. Account

2. Help

3. Checkout

4. Catalog

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

Слой работы с данными (группы методов для различных серверных API; Data Access Layer, DAL) в этом случае разделится на соответствующие сервисы, каждый из которых будет обслуживать свой набор экранов:

DAL\DataServices

AccountDataService.cs HelpDataService. cs

CheckoutDataService. cs CatalogDataService. cs

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

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

Рис. 5. Структура экранов по разделам

Имена экранов будут использоваться в названиях классов для соответствующих страниц и описания логики их поведения. При использовании паттерна MVVM и кроссплатфор-менного фреймворка Xamarin.Forms получатся следующие классы:

1.1 Profile

ProfilePage

ProfileViewModel

1.2 EmailLogin EmailLoginPage EmailLoginViewModel В первую очередь это важно для разработчиков, которые фактически получают готовую структуру проекта:

- Слой доступа к данным разбивается на разделы приложения - создается структура Data Access Layer (DAL)

- Добавляются нужные Pages и ViewModels — это создает структуру слоев работы с пользовательским интерфейсом и бизнес-логикой.

Пример структуры проекта представлен ниже.

Слой UI (User Interface, пользовательский интерфейс)

\Pages

\Account

ProfilePage.xaml

Слой BL (Business Logic, бизнес-логика)

\ViewModels

\Account

ProfileViewModel.cs

Слой DAL (Data Access Layer, доступ к данным)

\DataObjects (Models)

ProfileObj ect.cs (ProfileModel .cs) ProductObject.cs

\DataServices (Repositories)

AccountDataService.cs

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

2.2. Таблица экранов

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

1. Номер

2. Краткое название (Name)

3. Список возможных состояний (States)

4. Поля ввода для валидации (Validation)

5. Описание экрана и его поведения (Behavior)

В представленном наборе полей собрана та

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

Name

States

Validation

Behavior

Automation Id

1.3

Account

Profile

EmailLogin

Loading Normal Nolnternet NoData

Register

EditProfile

Email {>5 and <160, default email mask) Password (>2 and <24, any chars)

Email {>5 and <160, default email mask) Password (>2 and <24, any chars) Phone (12 digits, +X (XXX) XXX-XX-XX) FirstName (>2 any chars) LastName (>2 any chars)

Phone (12 digits, +X (XXX) XXX-XX-XX) FirstName (>2 any chars) LastName (>2 any chars)

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

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

EditButton

EmailField Password Fie Id LoginButton RegisterButton

EmailField

Password Fie Id

PhoneField

FirstNameField

LastNameField

RegisterButton

PhoneField FirstNameField LastNameField SaveButton

2 Help

Рис. 6. Таблица экранов

Дополнительно в эту таблицу могут быть добавлены следующие столбцы:

6. Список всплывающих уведомлений (alerts, sheets, dialogs)

7. Идентификаторы элементов пользовательского интерфейса (например, LoginButton) для написания автоматизированных тестов

8. Используемые модели (Models/Data Objects) данных

9. Используемые на каждом экране методы

DAL

10. Используемые стили (Styles)

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

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

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

- отображать индикатор прогресса загрузки;

- отображать загруженные данные;

- отображать сообщение об отсутствии интернет-соединения;

- отображать сообщение об ошибке (недоступен сервер, ошибки сервера);

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

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

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

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

Рис. 7. Состояния экранов 2.3. Карта переходов и состояний

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

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

пользователя, второй - для неавторизованного, а третий - из Рш^уведомления.

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

Рис. 8. Карта переходов

23

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

2.4. Стили и ресурсы

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

Сама по себе информация по стилю должна приходить от дизайнера (например, через сервис Zeplin.io или приложение Sketch). Необходимо для всех объектов на экране указать названия связанных стилей.

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

3. Пользовательские сценарии

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

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

1. Account

Case 1.1 Авторизация по email/паролю

Начальные условия устройство имеет высокоскоростное интернет-соединение, приложение запущено в первый раз или пользователь вышел из своего профиля. Отображается экран приветствия UI 1.2 EmailLogin

Ожидаемый результат пользователю отображается экран UI 1.1

Profile с загруженным профилем

UI Действие пользователя Реакция системы

1.3 Ввел Email, Пароль и нажал "Войти" (LoginButton) Если введены корректные email и пароль, то отобразится индикатор загрузки и осуществится автоматический переход на экран UI 1.1 Profile. В случае ошибок ввода данных пользователем должны отображаться сообщения об ошибках.

1.1 Ожидание На экране должны отобразиться загруженные данные из профиля (состояние экрана Normal)

Сценарии

Рис. 10. Финальный список артефактов после технического проектирования

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

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

Рис. 9. Пример пользовательского сценария Заключение

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

000

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

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

Литература

1. Tavakkoli Alireza. Game Development and Simulation with Unreal Technology. Boca Raton: CRC Press. 2016. 427 p.

2. Shekar Siddharth. Cocos2d Cross-Platform Game Development Cookbook. Packt Publishing Ltd. 2014. 266 p.

3. Скит Джон. C# для профессионалов: тонкости программирования; пер. с англ. Ю.Н. Артеменко. Изд. 3-е. М.: Вильямс, 2014. 608 с.

4. Hocking Joseph. Unity in Action. Multiplatform game development in C# with Unity 5. Manning. 2015. 352 p.

5. Торн Алан. Искусство создания сценариев в unity; пер. с англ. Р.Н. Рагимова. М.: ДМК-Пресс, 2016. 360 с.

6. Интеграционные решения при построении корпоративных информационных систем / В.В. Сафронов и др. // Известия Самарского научного центра РАН. 2016. Т. 18. № 4 (3). С. 646-654.

Поступила 25.06.2018; принята к публикации 10.09.2018 Информация об авторах

Черников Вячеслав Николаевич - соискатель, Воронежский государственный технический университет (394026, Россия, г. Воронеж, Московский проспект, 14), e-mail: [email protected]

Подвальный Семен Леонидович - д-р техн. наук, профессор, Воронежский государственный технический университет (394026, Россия, г. Воронеж, Московский проспект, 14), e-mail: [email protected]

Барабанов Владимир Федорович - д-р техн. наук, профессор, Воронежский государственный технический университет (394026, Россия, г Воронеж, Московский проспект, 14), e-mail: [email protected]

Нужный Александр Михайлович - канд. техн. наук, доцент, Воронежский государственный технический университет (394026, Россия, г Воронеж, Московский проспект, 14), e-mail: [email protected]

DEVELOPING PROCESS FORMALIZATION OF A USER CROSS-PLATFORM MOBILE

APPLICATION

V.N. Chernikov, S.L. Podvalny, V.F. Barabanov, A.M. Nuzhnyy Voronezh State Technical University, Voronezh, Russia

Abstract: the article describes the methodology for designing cross-platform mobile applications based on the user interface. The analysis of the software development procedure was performed and a list of the problems most frequently encountered by the development team and determined by the specifics of mobile business applications was determined. Based on the identified list of problems, the software development process was reviewed to identify the key steps that have the greatest impact on the speed and quality of coding and testing. An approach based on the visualization of a sequence of user transitions between application pages is described and the process of preliminary preparation of technical documentation that should be performed by the encoders and testers themselves is designed to unify the process of developing and using common terms and notations in technical documentation and program code. Methodical recommendations for creating a structure of cross-platform mobile applications based on the described technical documentation are given. The technique described in the article allows to carry out technical designing by the developers and testers, having received the information necessary for coding and testing in a convenient and visual format. The proposed approach allows to achieve a significant reduction in labor costs for the development and support of software products

Key words: cross-platform development, mobile applications, development methodology

References

1. Tavakkoli Alireza "Game Development and Simulation with Unreal Technology", CRC Press, Boca Raton, 2016, 427 p.

2. Shakar S. "Cocos2d cross-platform game development cookbook", Packt Publishing Ltd, 2014, 266 p.

3. Skeet J. "C# for professionals: the subtleties of programming", trans. from English by Artemenko Yu.N., Moscow, Williams, 2014, 608 p.

4. Hocking J. "Unity in action. Multiplatform game development inC# with Unity 5", Manning, 2015, 352 p.

5. Thorne A. "The Art of scripting in Unity", trans. from English by Ragimov R.N., Moscow, DMK-Press, 360 p.

6. Safronov V.V. et al. "Integration solutions in the construction of corporate information systems", Proceedings of the Samara scientific center of RAS (Izvestiya Samarskogo nauchnogo tsentra RAN), 2016, vol. 18, no. 4 (3), pp. 646-654.

Submitted 25.06.2018; revised 10.09.2018

Information about the authors

Vyacheslav N. Chernikov, Seeker, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), email: [email protected]

Semyen L. Podvalny, Dr. Sc. (Technical), Professor, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail: [email protected]

Vladimir F. Barabanov, Dr. Sc. (Technical), Professor, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail: [email protected]

Aleksandr M. Nuzhnyy, Cand. Sc. (Technical), Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail: [email protected]