79984

РЕФАКТОРИНГ КЛИЕНТСКИХ ПРИЛОЖЕНИЙ ДЛЯ ЭЛЕКТРОННОЙ ВАЛЮТНОЙ ТОРГОВЛИ НА ПЛАТФОРМАХ IOS И ANDROID

Дипломная

Информатика, кибернетика и программирование

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

Русский

2015-02-15

2.75 MB

1 чел.

МИНОБРНАУКИ РОССИИ

Томский государственный университет

Факультет информатики

Кафедра программной инженерии

ДОПУСТИТЬ К ЗАЩИТЕ В ГАК

Зав. кафедрой, профессор, д.ф.-м.н.

________________ О.А.Змеев

«___» ___________ 2013 г.

Ткачев Роман Владимирович

РЕФАКТОРИНГ КЛИЕНТСКИХ ПРИЛОЖЕНИЙ ДЛЯ ЭЛЕКТРОННОЙ ВАЛЮТНОЙ ТОРГОВЛИ НА ПЛАТФОРМАХ IOS И ANDROID

МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ

На соискание степени магистра

По направлению подготовки

010300 «Фундаментальная информатика и информационные технологии»

Руководитель ВКР, заведующий кафедрой программной инженерии

профессор, д.ф.-м.н.

____________ О.А.Змеев

       подпись

«_____»___________ 2013 г.

                                                                                               

                                                

Автор работы

                                                                                             студент группы № 1417

                                                                             _____________ Р.В.Ткачев

                                                                                                        подпись

 

Электронная версия магистерской диссертации   Администратор электронной

помещена в электронную библиотеку.        библиотеки факультета

                                                                             _____________ Е.Н.Якунина

                                                                                                        подпись

Томск 2013

Реферат

Выпускная квалификационная работа магистра 39 с., 18 рис., 9 источников.

Рефактоинг, МОБИЛЬНОЕ ПРИЛОЖЕНИЕ, ios, Android, АРХИТЕКТУРА ПРИЛОЖЕНИЯ, электронная валютная торговля.

Объект исследования - процесс проведения рефакторинга приложений на мобильных платформах iOS и Android.

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

Метод проведения работы: теоретический и экспериментальный.

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

Результаты работы внедрены в ООО «Е-Трейд Софт».


Содержание

[1] Перечень терминов и условных обозначений

[2] Введение

[3] 1 Рефакторинг приложения для электронной валютной торговли

[3.1] 1.1 Клиент для электронной валютной торговли

[3.2] 1.2 Анализ изначальной архитектуры и изучение ее слабых мест

[3.3] 1.3 Изучение и выбор методов решения обнаруженных проблем

[3.4] 1.4 Внесение изменений  в архитектуру

[4] 2 Особенности мобильных платформ

[4.1] 2.1 Особенности iOS

[4.2] 2.2 Особенности Android

[4.3] 2.3 Особенноти разработки под мобильные платформы

[4.4] 2.4.1 Нативная разработка приложений

[4.5] 2.4.2 Кроссплатформенная разработка приложений

[4.6] 2.5 Выбор метода разработки для нескольких платформ

[5] 3 Проведение рефакторинга клиентских приложений

[5.1] 3.1 Анализ структуры классов

[5.2] 3.2 Профилирование приложения

[5.3] 3.3 Выделение проблемных мест архитектуры и их рефакторинг

[5.4] 3.3.1 Обработка входящих и исходящих пакетов

[5.5] 3.3.1.1 Перегруженность классов

[5.6] 3.3.1.2 Однопоточная обработка пакетов

[5.7] 3.3.2 Хранение и отображение информации

[5.8] 3.3.2.1 Перегруженность классов

[5.9] 3.3.2.2  Не эффективный способ оповещения GUI

[5.10] 3.4 Оценка результатов проведения рефакторинга

[6] Заключение

[7] Список использованных источников

Перечень терминов и условных обозначений

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

SDK – (англ. software development kit) — комплект средств разработки, который позволяет создавать приложения для определённой платформы.

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

Котировка – текущая цена валютной пары.

Ордер – распоряжение на продажу/покупку определенной валютной пары по определенной цене.


Введение

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

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

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

В книге М. Фаулера [1] приводится следующее определение рефакторинга: «Рефакторинг - процесс такого изменения программной архитектуры, при котором не меняется внешнее поведение кода, но улучшается его внутренняя структура». Это способ систематического приведения кода в порядок, при котором шансы появления новых ошибок минимальны.

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

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

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


 1 Рефакторинг приложения для электронной валютной торговли

 1.1 Клиент для электронной валютной торговли

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

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

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

Приложение для электронной валютной торговли должно удовлетворять следующим требованиям:

  1.  высокая производительность;
  2.  малая потребность в ресурсах;
  3.  высокая скорость передачи данных.

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

В рамках первого жизненного цикла разработки клиентских приложений для платформ iOS и Android были реализованы два приложения.

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

Целевая платформа разработки выбиралась исходя из многочисленных исследований популярности мобильных платформ. Данные исследования ежегодно проводятся многими компаниями. Не смотря на то, что результаты у разных компаний могут различаться, общим в большинстве исследований является тот факт, что iOS и Android - наиболее распространенные платформы. Другие операционные системы, такие как Symbian и Windows Phone 7 существенно отстают от своих конкурентов.

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

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

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

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

 1.2 Анализ изначальной архитектуры и изучение ее слабых мест

 В целях повышения эффективности этап анализа архитектуры проходил в 2 этапа:

  1.  анализ структуры классов,
  2.  профилирование приложения.

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

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

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

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

 1.3 Изучение и выбор методов решения обнаруженных проблем

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

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

 1.4 Внесение изменений  в архитектуру

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

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

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

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

  1.  Провести анализ архитектуры  исходных приложений.
  2.  Выявить слабые места изначальной архитектуры и провести анализ решений для обнаруженных проблем.
  3.  Провести рефакторинг.

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


 2 Особенности мобильных платформ

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

2.1 Особенности iOS

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

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

  1.  Разработчики платформы советуют использовать для разработки язык Objective-C.  
  2.  Язык Objective-C не поддерживает множественное наследование.
  3.  iOS является закрытой платформой и как следствие довольно сильно ограничивает разработчика в доступе к системным функциям.
  4.  В iOS отсутствует сборщик мусора, поэтому при разработке необходимо тщательно следить за выделяемой памятью.

Для разработки приложений компания Apple предоставляет разработчикам пакет программ Xcode. Помимо среды разработки в пакет входят набор компиляторов, инструмент для разработки интерфейсов Interface Builder и другие полезные приложения.

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

 2.2 Особенности Android

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

Для разработки приложений на сайте компании Google доступен Android SDK, в который помимо библиотек входит Eclipse IDE со встроенным плагином Android Developer Tools. Приступая к разработке приложений для платформы Android, необходимо учитывать следующие особенности:

  1.  Жизненный цикл компонентов. С целью повысить эффективность использования памяти в операционной системе Android введен особый жизненный цикл компонентов. Самым сложным и наиболее важным для понимания жизненным циклом обладает активность (Activity). Подробное описание жизненного цикла активности можно найти в официальной документации на сайте компании Google.
  2.  Разработка логики может вестись как с использованием Java, так и с использованием C++.

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

 2.3 Особенноти разработки под мобильные платформы

В статье [8], посвященной методам разработки мобильных приложений, приводят следующие методы:

  1.  нативная разработка;
  2.  кроссплатформенная разработка

Рассмотрим каждый метод подробнее.

 2.4.1 Нативная разработка приложений

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

Для iOS – это  приложения, написанные на Objective-C с использованием iOS SDK, а для Android приложения, написанные на Java с использованием Android SDK.

Для каждой из данных платформ написано большое количество книг и статей по нативной разработке. В качестве примера для платформы для платформы iOS можно назвать  «Профессиональное программирование приложений для iPhone и iPad» [5], для Android - «Программирование под Android» [6]. К тому же, производители предоставляют исчерпывающую онлайн-документацию по соответствующим SDK с описанием всех классов и пакетов.

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

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

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

Распространение готовых приложений осуществляется посредствам специальных магазинов приложений. Для iOS таковым является App Store, для AndroidGoogle Play. Для публикации приложений необходимо наличие платной лицензии. Однако, помимо лицензии, магазины так же проводят проверку приложений на наличие вредоносного кода, функциональности, нарушений чьих-либо авторских прав и т.п.

2.4.2 Кроссплатформенная разработка приложений

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

В результате веб-разработки создается веб-приложение, которое запускается внутри браузера, установленного на мобильном устройстве. Для разработки такого приложения используются Java Script, HTML 5, CSS 3 и другие технологии и инструменты веб-разработки.

Авторы статьи [8]  разделяют веб-приложения на 2 вида: сайты, адаптированные для просмотра на мобильных устройствах и полноценные веб-приложения, каждое из которых может быть запущенно как и нативное приложение и почти ничем не отличается от него визуально.

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

Кроме того, достоинством веб-подхода так же является обилие различных Java Script библиотек, существенно ускоряющих процесс разработки. К качестве примера такой библиотеки можно привести jQuery Mobile.

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

Гибридный подход объединяет в себе особенности двух предыдущих. Гибридное приложение, представляет из себя веб-приложение в нативной «оболочке», позволяющей запускать веб-часть вне браузера.

Данный подход позволяет работать приложению без подключения к сети Интернет.

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

2.5 Выбор метода разработки для нескольких платформ

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

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

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

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

3 Проведение рефакторинга клиентских приложений

3.1 Анализ структуры классов

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

Вся система базируется на клиент-серверной архитектуре. На рисунке 1 представлена общая структура клиентского приложения.

Рис. 1 Общая структура клиентского приложения

Пакет NetLayer содержит в себе всю логику, связанную с обменом информацией с серверами. Пакет DataStorage представляет собой локальное хранилище данных и содержит в себе всю логику, связанную с хранением и обработкой  торговых данных. Пакет GUI содержит всю логику связанную с пользовательским интерфейсом. Server – совокупность серверов, данный пакет стоит обособленно и в явном виде не входит в архитектуру клиентского приложения.

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

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

Рис. 2 Диаграмма классов клиентского приложения

Классы:

  •  NetLayerApi содержит в себе логику приема, отправки и обработки пакетов.
  •  Packer осуществляет упаковку и распаковку пакетов, а также определяет алгоритм шифрования для каждого пакета.
  •  Package класс для пакетов, определяет базовые поля всех пакетов, а также реализует процедуру кодирования и декодирования этих полей.
  •  Encoder содержит реализации алгоритмов шифрования.
  •  AppData хранит и обрабатывает торговую информацию и используется для оповещения класса делегата об изменениях в данных.
  •  InformationExpert производит на основе приходящих данных  различные торговые расчеты, такие как кросс-курсы, прибыль и др.
  •  Soket класс-обертка над стандартным сокетом, осуществляющий прием и передачу потока данных.

3.2 Профилирование приложения

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

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

  1.  для iOS использовался профайлер, встроенный в систему разработки Xcode поставляемой Apple.
  2.  для Android использовался профайлер Traceview поставляемый компанией Google.

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

Рис. 3 Основное окно профайлера

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

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

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

 3.3 Выделение проблемных мест архитектуры и их рефакторинг

Всю логику приложения можно разделить на следующие области:

  1.  обработка входящих и исходящих пакетов;
  2.  хранение и отображение данных.

Рассмотрим каждую из областей более подробно.

 3.3.1 Обработка входящих и исходящих пакетов

За обработку входящих и исходящих пакетов отвечают следующие классы:

  •  Soket класс-обертка над стандартным сокетом, осуществляющий прием и передачу потока байт.
  •  NetLayerApi отвечает за получение и отправку пакетов, за преобразование потока байт в объект и последующую передачу  его в Packer для дальнейшей распаковки. Реализация этого класса занимает порядка 3000 строк кода, что является крайне не удобным для дальнейшей разработки.
  •  Packer осуществляет упаковку и распаковку пакетов, а также определяет алгоритм шифрования для каждого пакета, также реализация этого класса составляет порядка 1500 строк кода.
  •  Package класс для пакетов, определяет базовые поля всех пакетов, а также реализует процедуру кодирования и декодирования этих полей.
  •  Encoder содержит реализации алгоритмов шифрования.

Диаграмма этих классов представлена на рисунке 4.

Рис. 4 Диаграмма классов отвечающих за обработку пакетов

Распаковка пришедшего пакета происходит следующим образом:

  1.  В Soket приходит поток байт.
  2.  NetLayerApi читает из Socket один пакет.
  3.  Сырые данные передаются в Packer для распаковки
  4.  Packer внутри себя определяет каким алгоритмом шифрования будет расшифрован пакет и передает его в соответствующий метод Encoder.
  5.  После расшифровки Encoder возвращает уже расшифрованные данные.
  6.  После этого Packer определяет тип пакета, создает экземпляр Package и  формирует в нем набор полей соответствующих данному типу пакета.
  7.  Экземпляр Package возвращается в NetLayerApi, где впоследствии происходит дальнейшая обработка.

На рисунке 5 представлена диаграмма этого процесса.

Рис. 5 Распаковка пакетов

Упаковка пакета происходит в обратном порядке:

  1.  В GUI формируется экземпляр Package и передается в NetLayerApi.
  2.  NetLayerApi передает Package в Packer.
  3.  Все поля этого пакета превращаются в набор байт, которые затем шифруются.
  4.  Затем Packer возвращает данные в NetLayerApi, который в свою очередь отпраляет их при помощи Soket на сервер.  

На рисунке 6 представлена диаграмма этого процесса.

Рис. 6 Упаковка объектов

 Из всего вышесказанного можно выделить следующие проблемы данной подсистемы:

  1.  Малое зацепление приводит к не эффективному распределению работы между классами.
  2.  Обработка пакетов происходит последовательно, т.е. каждый пришедший на обработку пакет проходит все стадии, в том числе и вывод изменений данных, вызванные этим пакетом, на экран. Такой подход очень сильно замедляет скорость обработки пакетов.
  3.  Для получения информации с нескольких серверов одновременно NetLayerApi поддерживает  связь через несколько экземпляров Socket, но обработка данных со всех сокетов производится в единственном потоке, что ведет к значительным задержкам.
  4.  Чтение из Socket очередного пакета происходит только после завершения обработки предыдущего пакета. При таком подходе тратится очень много времени на считывание потока байт из сокета.
  5.  Создание пакетов запросов происходит в GUI. Такой подход является не очень удобным, так как создание пакетов для запросов может происходить, к примеру, в нескольких окнах и в случае изменения  структуры пакетов придется изменять код во всех этих местах.

Рассмотрим данные проблемы и способы их решения более подробно.

 3.3.1.1 Перегруженность классов

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

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

          

Рис. 7 Диаграмма классов системы отправки пакетов

Класс NetLayerApi при помощи Soket поддерживает соединении со всеми необходимыми серверами, отправляет все пакеты на распаковку и после распаковки производит необходимые действия.

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

Рис. 8 Диаграмма классов системы отправки пакетов после рефакторинга

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

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

 

Рис.9 Диаграмма классов системы упаковки/распаковки пакетов

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

Для того чтобы разгрузить Packer необходимо сделать следующее:

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

На рисунке 10 представлена диаграмма классов с внесенными изменениями.

Рис. 10 Диаграмма классов системы упаковки/распаковки пакетов после рефакторинга

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

Также к этому типу проблем можно отнести создание пакетов для запросов внутри GUI. Данная проблема проиллюстрирована на рисунке 11.

Рис.11

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

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

  •  Soket класс-обертка над стандартным сокетом, осуществляющий прием и передачу потока байт.
  •  Channel отвечает за получение и отправку пакетов, а также за отправку пакетов в Packer для дальнейшей распаковки.
  •  Packer осуществляет упаковку и распаковку пакетов.
  •  Encoder отвечает за выбор алгоритма шифрования.
  •  Cipher определяет общий интерфейс для всех алгоритмов шифрования.
  •  Package – класс прародитель для всех классов пакетов, определяет интерфейс для упаковки и распаковки пакета.
  •  NetLayerApi теперь отвечает только за обработку уже распакованных пакетов, а также служит для создания пактов запросов.

На рисунке 12 представлена диаграмма классов переработанной системы обработки пакетов.

Рис. 12 Диаграмма переработанной системы обработки пакетов

 3.3.1.2 Однопоточная обработка пакетов

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

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

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

  1.  В Soket приходит поток байт.
  2.  Channel читает из Socket  все пришедшие данные и записывает их в буфер. Запись данных в буфер позволяет сэкономить немного времени на чтении из сокета.
  3.  В случае если в буфере находятся несколько пакетов, то они поочередно извлекаются из него и для обработки каждого пакта создается еще один поток.
  4.   Сырые данные передаются в Packer для распаковки.
  5.  Packer передает данные в Encoder, который внутри себя определяет каким алгоритмом следует расшифровать и передает в соответствующий класс для расшифровки.
  6.  Encoder возвращает расшифрованные данные обратно в Packer
  7.  Packer определяет тип пакета, создает для него экземпляр класса соответствующего этому типу и передает в него расшифрованные данные.
  8.  После того как экземпляр класса пакета закончит распаковывать данные, он будет передан обратно в Channel.
  9.  После того как Channel получает из распаковки пакет, он передает его в NetLayerApi.
  10.   NetLayerApi получив распакованный пакет пиступит к его обработке.

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

Рис. 13

Упаковка же объектов происходит немного подругому:

  1.  GUI вызывает у NetLayerApi метод создания необходимого запроса.
  2.  NetLayerApi создает и инициализирует экземпляр класса соответствующего пакету запроса.
  3.  Инициализированный экземпляр передается в соответствующий Cannel, где он передается в Packer.
  4.  В Packer у класса пакета вызывается метод Pack,  который возвращает упакованные данные пакета.
  5.  Затем упакованные данные передаются на шифрование в Encoder.
  6.  Encoder определяет алгоритм шифрования и передает данные на шифровку нужному классу.
  7.  После этого Encoder возвращает зашифрованные данные в Packer, а тот в свою очередь отправляет их в Channel.
  8.  Channel при получении зашифрованных данных отправляет их посредствам Socket на сервер.   

На рисунке 14 представлена диаграмма этого процесса.

Рис.  14

 3.3.2 Хранение и отображение информации

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

Рис. 15

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

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

В связи с выше сказанным выделяются следующие проблемы:

  1.  Перегрузка данными и логикой класса AppData.
    1.  Крайне не эффективный способ оповещения GUI.

Рассмотрим данные проблемы подробнее.

 3.3.2.1 Перегруженность классов

Как и в случае с обработкой пактов, решением данной проблемы является декомпозиция логики на более мелкие подзадачи и выделение их в отдельные классы. В случае же с AppData решением является выделение хранилищ различных не связанных друг с другом объектов таких как котировки и новости в отдельные классы. В AppData же остается только логика связанная с оповещением GUI и с распределением пакетов с данными между отдельными хранилищами. На рисунке 16 изображена диаграмма классов с внесенными изменениями.

Рис. 16

 3.3.2.2  Не эффективный способ оповещения GUI

Как уже говорилось, оповещение GUI производилось путем вызова жестко зашитых методов у класса, переданного в поле delegate в классе AppData. Подобный поход крайне не удобен и опасен.

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

На рисунке 17 изображена диаграмма классов реализованного паттерна.

Рис. 17

3.4 Оценка результатов проведения рефакторинга

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

Рис. 18

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

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

Заключение

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

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

Результаты работы внедрены в ООО «Е-Трейд Софт».


Список использованных источников

  1.  Рефакторинг: улучшение существующего кода/ Фаулер М., Бек К., Брант Д., Робертс Д., Апдайк У. - Спб: Символ-Плюс, 2009. - 432 с.
  2.  Программирование сетевых приложений на С++/ Шмидт Д., Хьюстон С. – М.: Бином, 2011. – 304 с.
  3.  Райзберг Б.А., Лозовский Л.Ш., Стародубцева Е.Б.. Современный экономический словарь. — 2-е изд., испр. М.: ИНФРА-М, 1999.
  4.  Программирование под Android/ Медникс З., Дорнин Л., Мик Б., Накамура М. – Спб.:Питер, 2012. – 496 с.
  5.  Профессиональное программирование приложений для iPhone и iPad / Джин Баклин. – М.: Эксмо, 2012. – 672 с.
  6.  Android (operating system) [Электронный ресурс] From Wikipedia, the free encyclopedia. URL: https://en.wikipedia.org/wiki/Android_%28operating_system%29 (дата обращения 20.05.2013).
  7.   iOS [Электронный ресурс] From Wikipedia, the free encyclopedia. URL: http://ru.wikipedia.org/wiki/IOS (дата обращения 20.05.2013).
  8.  IBM Software. Native, web or hybrid mobile-app development. [Электронный ресурс]    URL: http://www.computerworld.com.au/whitepaper/371126/native-web-or-hybrid-mobile-app-development/download/ (дата обращения 18.04.2013).
  9.  Design Patterns [Электронный ресурс] From Wikipedia, the free encyclopedia. URL: http://en.wikipedia.org/wiki/Design_Patterns (дата обращения 03.05.2013).


 

А также другие работы, которые могут Вас заинтересовать

33354. Общие сведения о радиолиниях связи. Основные понятия и определения. Классификация диапазонов радиочастот и радиоволн. Особенности распространения радиоволн метрового и миллиметрового диапазонов 18.21 KB
  Классификация диапазонов радиочастот и радиоволн. Особенности распространения радиоволн метрового и миллиметрового диапазонов. Классификация диапазонов радиочастот и радиоволн. Радиосвязь вид электросвязи осуществляемый с помощью радиоволн.
33355. Обеспечение дальности связи. Радиорелейные, тропосферные и спутниковые линии (системы) передачи (связи). Магистральные кабельные линии (системы) передачи 64.86 KB
  Радиорелейные тропосферные и спутниковые линии системы передачи связи. Магистральные кабельные линии системы передачи. Радиолинии передачи 6. Радиорелейные линии передачи Радиолиния передачи в которой сигналы электросвязи передаются с помощью наземных ретрансляционных станций называется радиорелейной линией передачи.
33356. Открытые системы и их взаимодействие. Эталонная модель взаимодействия открытых систем. Основные понятия и определения 27.2 KB
  Прикладной процесс Системы А сообщается с Уровнем 7 Системы А верхний уровень который сообщается с Уровнем 6 Системы А который в свою очередь сообщается с Уровнем 5 Системы А и так далее до Уровня 1 Системы А. После того как информация проходит через физическую среду и принимается Системой В она поднимается через слои Системы В в обратном порядке сначала Уровень 1 затем Уровень 2 и т. пока она наконец не достигнет прикладного процесса Системы В.
33357. Характеристика уровней эталонной модели (назначение, основные функции) 14.34 KB
  Описание уровней эталонной модели OSI Каждый уровень имеет заранее заданный набор функций которые он должен выполнить для проведения связи. Прикладной уровень уровень 7 это самый близкий к пользователю уровень OSI. Прикладной уровень идентифицирует и устанавливает наличие предполагаемых партнеров для связи синхронизирует совместно работающие прикладные процессы а также устанавливает и согласовывает процедуры устранения ошибок и управления целостностью информации. Прикладной уровень также определяет имеется ли в наличии достаточно...
33358. Принципы построения систем и сетей связи на основе эталонной модели 27.29 KB
  Пример представления процесса связи на основе уровней OSI Прикладной процесс Системы А сообщается с Уровнем 7 Системы А верхний уровень который сообщается с Уровнем 6 Системы А который в свою очередь сообщается с Уровнем 5 Системы А и так далее до Уровня 1 Системы А. После того как информация проходит через физическую среду и принимается Системой В она поднимается через слои Системы В в обратном порядке сначала Уровень 1 затем Уровень 2 и т. пока она наконец не достигнет прикладного процесса Системы В. Каждый из уровней сообщается...
33359. Универсальный асинхронный приёмо-передатчик КР1816ВУ51 32 KB
  Через универсальный асинхронный приёмопередатчик УАПП осуществляется прием и передача информации представленной последовательным кодом младшими битами вперёд в полном дуплексном режиме обмена. В этом режиме информация 8бит передаётся и принимается через внешний вывод входа приёмника RXD. Через TXD выдаются импульсы сдвига синхронизации которые сопровождают каждый бит. За один машинный цикл передаётся один бит информации.
33360. Система прерываний КР1816ВУ51 48 KB
  Система развивается с появлением новых типов микроконтроллеров этой серии число источников прерываний постоянно увеличивается и достигло в некоторых пятнадцати. Рассмотрим систему прерываний МК51. Из пяти источников прерываний внешними являются входы INT0 и INT1 а внутренними – два счетчика таймера и последовательный порт.
33361. Система команд КР1816ВУ51 33 KB
  Всего в системе команд семейства MК51 можно выделить 5 групп: команды арифметических операций команды логических операций команды пересылки данных команды операций с битами и команды передачи управления. Команды операций с битами Эти команды устанавливают в 1 SETB или 0 CLR прямоадресуемый бит внутренней памяти данных изменяют его значение на противоположное CLR выполняют операции ND и OR над флагом переноса С и прямоадресуемым битом ND и ORL осуществляют пересылку значения между флагом С и прямоадресуемым битом MOV...
33362. Типовая схема СУ на базе КР1816ВУ51 27 KB
  В случае если производительность процессора микроконтроллера достаточна для решения поставленной задачи эту проблему можно решить организацией системы шин к которым и подключаются все необходимые устройства. Кроме достаточной производительности микроконтроллер должен иметь возможность подключения внешней памяти данных. Микроконтроллер МК51 обладает такой возможностью.