Огляд існуючих розробок веб-сервісів ведення спортивної статистики і програмного забезпечення прийому замовлень для служб таксі

Вступ

Основним двигуном прогресу в розвитку web-технологій є проекти, орієнтовані на багатомільйонну аудиторію і здатні витримувати високе навантаження на ресурси (більше 1000 запитів за секунду). По-перше, для реалізації подібних проектів необхідно максимально ефективно оптимізувати програмний код, по-друге, — використовувати потужну апаратуру.

На поточному етапі розвитку IT-технологій спостерігається тенденція завоювання міцних позицій смартфонами. Основними їх перевагами є зручність, наявність ряду вбудованих функцій (GPS-навігація, акселерометр, гіроскоп, мобільний зв’язок, фотоі відео-камера та ін.), а також те, що вони здатні виконувати більшість функцій стаціонарних комп’ютерів і ноутбуків. З кожним днем все більше людей відкривають для себе переваги смартфонів, тому багато високонавантажених Інтернет-сервісів зараз працюють в зв’язці з мобільними пристроями.

У магістерській роботі розробляється проект ведення спортивної статистики, першим компонентом якого є додаток для смартфонів сімейства iPhone, основною функцією якого є збір статистики, другим — веб-сервер, який синхронізується з додатком і видає дані на сайт.

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

Наукова новизна. Запропоновані організація системного програмного забезпечення, що виконує автоматичний підрахунок виконаних фізичних вправ (підтягувань, віджимань і т. п.), і створення спеціальної соціальної мережі із специфічним набором функцій, орієнтованих на ведення спортивної статистики. Запропонована система прийому замовлень для служб таксі і збору специфічних у цій галузі даних.

Мета магістерської роботи. Розробка універсального алгоритму і програмного забезпечення для автоматичного підрахунку фізичних вправ і ведення спортивної статистики, створення відповідної соціальної мережі, здатної витримувати високі навантаження на ресурси (більше 1000 запитів за секунду). Розробка веб-сервісу прийому замовлень для служб таксі.

Виходячи з мети були поставлені наступні задачі:

— дослідження вбудованого акселерометра, розробка алгоритму автоматичного підрахунку фізичнх вправ і його практична реалізація у вигляді програмного продукту для смартфонів сімейства iPhone;

— налаштування сервера, здатного витримувати високі навантаження на ресурси (більше 1000 запитів в секунду), розробка API для взаємодії з додатком для смартфону і створення соціальної мережі з необхідним набором функцій;

— поширення програмного продукту і тестування його роботи і роботи сервера на реальній аудиторії з високим навантаженням на ресурси;

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

Реалізація і упровадження результатів роботи. Під час науково-дослідної практики був укладений договір з компанією Apple Inc. на отримання права розробляти і розміщувати додатки в офіційному магазині. Розроблений проект SportDiary був розміщений в App Store у вересні 2012 року.

Апробація роботи: основні наукові результати роботи доповідались на науково-технічній конференції «Информационные управляющие системы и компьютерный мониторинг» (Донецьк, ДонНТУ — 2012), та багаторазово на спеціалізованих семінарах.

Структура і об'єм магістерської роботи:

Робота складається зі вступу, 5 глав, виводу, переліку посилань (15 найменувань), містить 100 сторінок тексту, 50 рисунків, 3 таблиці і 2 доповнення.

У першому розділі приводиться огляд аналогічних розробок додатків збору спортивної статистики для мобільних пристроїв і огляд аналогічних проектів по прийому замовлень для служб таксі.

У другому розділі розробляється загальна структура проекту ведення спортивної статистики. Приводиться дослідження вбудованого в мобільний пристрій акселерометра і розробка алгоритму автоматичного підрахунку виконаних фізичних вправ. Описана розробка кінцевої версії мобільного додатку і використаних технологій.

У третьому розділі приводиться розробка специфічної соціальної мережі, призначеної для користувачів мобільного додатка SportDiary. Проведений огляд використаних технологій і налаштування сервера. Описаний процес забезпечення взаємодії соціальної мережі з мобільним застосуванням. Проведено розміщення проекту у відкритому доступі і його тестування на реальних користувачах.

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

У п’ятому розділі приведені основні положення охорони праці, проведений розрахунок кондиціонування, освітлення і шуму в приміщенні.

1. Огляд існуючих розробок веб-сервісів ведення спортивної статистики і програмного забезпечення прийому замовлень для служб таксі

акселерометр програмний сервер смартфон Аналогічні проекти по веденню спортивної статистики можна розділити на 3 категорії:

1) додатки, які орієнтовані тільки на ведення статистики і планування режиму тренувань;

2) додатки, які орієнтовані на ведення статистики з дистанційних вправ (біг, їзда на велосипеді і т. п.) з використанням вбудованого GPS-навігатору;

3) додатки, які орієнтовані на ведення статистики з силових вправ (віджимання, підтягування і т. п.) з використанням вбудованого акселерометра, гіроскопа і відео-камери.

Оскільки у рамках магістерської роботи додаток розробляється для смартфонів сімейства iPhone, аналіз існуючих проектів проводиться серед аналогічних пристроїв.

Додатки, орієнтовані тільки на ведення статистики і планування режиму тренувань передбачають можливість введення даних тільки вручну для будь-яких типів вправ. В основному подібні проекти розраховані на аудиторію людей, які займаються в тренажерному залі. У таких додатках не передбачений автоматичний підрахунок повторень і не використовуються вбудовані акселерометр, гіроскоп, GPS-навигатор і камера.

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

Одним з найбільш відомих і багатофункціональних проектів є додаток «Endomondo Sports Tracker». Основними його функціями є:

— зображення пройденого маршруту на карті;

— реєстрація і збереження різних статистичних даних (пройдена дистанція, час, швидкість, втрачені калорії і т. п.). Більшість даних збираються за допомогою вбудованого в iPhone акселерометра;

— синхронізація даних з сервером;

— публікація даних в соціальній мережі.

У проект «Endomondo Sports Tracker» також входить соціальна мережа, в якій кожен користувач може ділитися своїми маршрутами і статистичними даними з іншими користувачами.

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

Рисунок 1.1 — Інтерфейс додатка «Endomondo Sports Tracker» з приведеною статистикою Додатки, орієнтовані на ведення статистики силових вправ найбільш близькі за змістом до проекту, що розроблюється в магістерській роботі. Для підрахунку повторень в них використовуються можливості вбудованого акселерометра, рідше — відеокамери. Недоліком подібних застосувань є те, що статистику можливо вести тільки для фіксованого набору вправ. Додавати свої вправи не можна.

Одним з перших і найбільш успішних застосувань, в яких використовується автоматичний підрахунок фізичних вправ, є додаток «Push-ups».

Принцип його роботи полягає в тому, що реєстрація кожного нового повторення здійснюється за допомогою вбудованої передньої відео-камери. Людина повинна покласти телефон на підлогу, і віджиматися, ледве торкаючись телефону грудьми. Камера фіксує затемнення екрану і рахує їх за повторення. Цей додаток розрахований на ведення статистики, але не включає вбудовану соціальну мережу. Істотним недоліком додатка є те, що він розрахований тільки на підрахунок віджимань з причини специфіки алгоритму. Інтерфейс додатка, на якому зображена зібрана статистика з віджимань, приведений на рисунку 1.2.

Вбудований в iPhone акселерометр використовувався для підрахунку фізичних вправ в додатку «FitFu» (на момент оформлення магістерської роботи додаток був видалений з продажу). У цьому проекті використовувалася власна соціальна мережа, в якій користувачі могли публікувати свої досягнення. Проте істотним недоліком додатка є те, що він реалізований у вигляді гри, і не передбачає ведення статистики і додавання власних вправ. Автоматичний підрахунок може виконуватися тільки для фіксованої кількості вправ, серед яких немає багатьох базових і найбільш популярних.

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

Рисунок 1.2 — Інтерфейс додатка «Push-ups» з приведеною статистикою У рамках магістерської роботи пропонується усі проекти з прийому замовлень для служб таксі класифікувати за наступними критеріями:

— по наявності підтримки функцій GPS:

а) з підтримкою функцій GPS. У таких проектах робиться замовлення через сайт або мобільний додаток за допомогою мітки на карті і пошук вільних машин, які відмічені на карті;

б) без підтримки функцій GPS. У таких проектах замовлення робиться по телефону або за допомогою SMS-сообщения і пошук таксистів — без задіювання відповідних API;

— по організації роботи:

а) повністю автоматизовані. Замовлення і пошук машини ведеться автоматично, без участі роботи диспетчера;

б) напівавтоматизовані. Частина роботи покладається на диспетчера (наприклад, прийом замовлення по телефону), частина роботи виконується автоматично (наприклад, пошук вільної машини);

— за способом вибору вільної машини:

а) з використанням черги. Вибирається перша машина в черзі, в якій відзначаються таксисти;

б) з використанням пошуку найближчої машини. Вибирається машина, яка знаходиться в даний момент щонайближче до адреси, на яку робився виклик;

в) по вибору клієнта. Клієнт сам вибирає найбільш зручну йому машину з усіх можливих, які відмічені на карті.

Одним з аналогічних проектів є місцеве таксі міста Донецьк. Принцип його роботи полягає в наступному. Клієнт робить дзвінок диспетчерові. Замовлення може робитися тільки по телефону. Диспетчер отримує адресу, на яку треба послати машину і вводить цю адресу в базу поточних замовлень. Диспетчери діляться на дві категорії:

1) диспетчери, які спілкуються з клієнтами і приймають замовлення;

2) диспетчери, які спілкуються з таксистами і беруть участь в розподілі замовлень.

На локальному сервері знаходиться система обробки замовлень, яка розподіляє замовлення між таксистами. Якщо на замовлення, що поступило, немає жодного вільного таксиста, диспетчер просить клієнта почекати, поки з’явиться вільна машина. Якщо в потрібному районі є вільний таксист, замовлення відправляється йому.

Для кращої організації розподілу замовлень існує черга таксистів. Нове замовлення, що поступило, вирушає першій в цій черзі машині. Кожному таксистові видається мобільний Java-додаток, за допомогою якого він може відзначатися в черзі і отримувати повідомлення про замовлення, що поступили.

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

Недоліком цієї схеми роботи прийому замовлень полягає в наступному:

— не оптимальна витрата бензину (на замовлення часто прибуває вільний таксист, який знаходиться не щонайближче до необхідної адреси);

— часто виникають ситуації, коли пошук вільної машини затягується більш ніж на 1 хвилину;

— в пікові моменти завантаження служби таксі часто виникають ситуації перевантаження лінії зв’язку і пропуску дзвінків.

Другим аналогічним проектом є «Яндекс Таксі». Користуватися послугами «Яндекс Таксі» можна як через браузер, так і через мобільні додатки для смартфонів iPhone і Android. На момент написання магістерської роботи сервіс працював тільки в Москві.

Принцип роботи «Яндекс Таксі» полягає в тому, що система сама підбирає вільний автомобіль який знаходиться щонайближче до клієнта. Для замовлення машини необхідно вказати адресу, на яку викликається машина, і пункт призначення, а також час, коли повинне прибути таксі. Клієнт отримує інформацію про те, скільки приблизно триватиме поїздка з урахуванням пробок. Також можна вказати особливі вимоги до автомобіля (кондиціонер, салон для некурящих або курящих і т. п.). Клієнт бачить на карті усі вільні на даний момент таксі в режимі реального часу.

Клієнтові надається інформація про викликаний автомобіль: служба таксі і її рейтинг, тариф, дані про водія, номер його телефону, колір і марка автомобіля, а також його номер. Для підтвердження виклику необхідно ввести номер свого мобільного телефону або зайти в Яндекс під своїм акаунтом. Під час виклику на карті можна спостерігати рух таксиста в режимі реального часу.

Слід виділити наступні переваги такого роду системи виклику таксі:

— швидкий підбір ближчої машини;

— можливість клієнта самостійно вибирати характеристики автомобіля;

— здатність системи витримувати високе навантаження на ресурси;

— економія коштів на послугах диспетчера і купівлі додаткового обладнання (рацій).

На даний момент існує тенденція переходу на автоматизовані системи прийому замовлень.

2. Розробка структури проекту ведення спортивної статистики і оффлайн-версії мобільного додатку для IPhone

2.1 Розробка загальної структури проекту ведення спортивної статистики

Проект SportDiary включає мобільний додаток для смартфонів iPhone, який працює в зв’язці із спеціально розробленою соціальною мережею. Узагальнена схема роботи проекту SportDiary зображена на рисунку 2.1.

Мобільне застосування виконує наступні функції:

1) автоматичний підрахунок кількості повторень виконаної фізичної вправи за допомогою вбудованого в мобільний пристрій акселерометра;

2) ведення статистики по кожній вправі (зібрані дані по вправах зберігаються в локальну базу даних і видаються користувачеві у вигляді графіку);

3) редагування статистики вручну;

4) видалення і додавання будь-яких вправ;

5) зберігання базових персональних даних користувача (логін і пароль для входу в соціальну мережу, ім'я, фото);

6) синхронізація даних з сервером за наявності Інтернету;

7) перегляд даних будь-якого користувача соціальної мережі за наявності Інтернету;

8) пошук по користувачах;

9) можливість підписки на користувача.

Соціальна мережа sportdiary.net виконує наступні функції:

1) перегляд даних, синхронізованих з мобільним додатком, перегляд статистики по кожній вправі;

2) пошук користувачів;

3) перегляд даних будь-якого користувача;

4) коментування вправ користувачів.

Структура проекту SportDiary приведена на рисунку.

Структура проекту SportDiary

Проект розрахований тільки на користувачів смартфонів iPhone, починаючи з 4 серії. Мобільний додаток SportDiary розрахований на аудиторію, яка займається фитнесом і виконує стандартні фізичні вправи. Автоматичний підрахунок повторень виконаної фізичної вправи робиться за допомогою вбудованого в мобільний пристрій акселерометра.

Отримані дані зберігаються в локальну базу даних SQLite. Статистика по кожній вправі може бути виведена на дисплей смартфону.

При підключенні iPhone до інтернету оновлені дані з локальної бази даних синхронізуються з сервером і записуються в базу даних SQL на сервері.

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

Доступ до соціальної мережі можна отримати як з мобільного застосування, так і безпосередньо на веб-сайті www.sportdiary.net. В соціальній мережі можна проглянути дані будь-якого користувача: фотографію, ім'я, усі вправи, статистику по кожній вправі.

2.2 Дослідження вбудованого в мобільний пристрій акселерометра і розробка алгоритму автоматичного підрахунку виконаних фізичних вправ

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

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

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

Принцип дії акселерометра полягає в тому, що при будь-якому русі смартфону реєструються відповідні прискорення по трьом осях X, Y, Z.

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

За початкове прискорення по певній осі, якщо та знаходиться перпендикулярно опорі, прийнято прискорення g = 9.81 м/с².

Спрощений принцип роботи вбудованого в iPhone акселерометра У iPhone прийняті наступні орієнтації пристрою в просторі:

1) Portrait Up — смартфон розташований у вертикальному положенні, нижня кнопка дивиться вниз, прискорення по осі Y дорівнює - g, по інших осях — нуям;

2) Portrait Down — смартфон розташований у вертикальному положенні, нижня кнопка дивиться вгору, прискорення по осі Y дорівнює +g, по інших осях — нулям;

3) Landscape Right — смартфон розташований в горизонтальному положенні, нижня кнопка дивиться вправо, прискорення по осі X дорівнює - g, по інших осях — нулям;

4) Landscape Left — смартфон розташований в горизонтальному положенні, нижня кнопка дивиться вліво, прискорення по осі X дорівнює +g, по інших осях — нулям;

5) Face Up — смартфон розташований паралельно поверхні землі, екран дивиться вгору, прискорення по осі Z дорівнює - g, по інших осях — нулям;

6) Face Down — смартфон розташований паралельно поверхні землі, екран дивиться вгору, прискорення по осі Z дорівнює +g, по інших осях — нулям.

При якому-небудь переміщенні смартфону в просторі значення прискорення по осях X, Y, Z змінюються.

У всіх вище вказаних вправ існує загальна особливість — одне повторення вправи складається з руху вгору-вниз, або вниз-вгору. Таким чином, існує можливість об'єднати підрахунок усіх вправ в один алгоритм.

Для дослідження сигналу від акселерометра і розробки алгоритму було використано безкоштовне застосування для iPhone Sensor Monitor, яке надає сигнал від різних датчиків смартфону у вигляді графіків. Інтерфейс додатка Sensor Monitor приведений на рисунку.

Поле Freq. служить для вибору частоти опитування акселерометра, яка вимірюється в Гц. Чим вище частота опитування акселерометра, тим більш точно видається графік сигналу. У додатку Sensor Monitor можливо встановити 4 значення частоти опитування акселерометра: 30, 60, 90 і 120 Гц. Для реєстрації одного повторення вправи навіть частота 30 Гц є надмірною, оскільки навіть в найшвидшому темпі дуже складно зробити навіть 2 повторення будь-які з вправ. Тому подальші дослідження акселерометра проводяться на частоті 30 Гц.

Лівіше за поле Freq. виводяться значення прискорення по кожній з осей X, Y, Z. Значення змінюються з вказаною частотою.

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

Інтерфейс додатка Sensor Monitor

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

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

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

При виконанні цієї вправи iPhone знаходився в орієнтації Portrait. Для фіксації смартфону досить покласти його в кишеню або тримати в руках. Як видно з графіку, дані по осях X і Z мало коливаються, і дуже складно виділити які-небудь пікові області. Значення прискорення по осі Х приблизно прагне до нуля. Тому для реєстрації повторень в даному випадку необхідно аналізувати дані, отримані по осі Y.

Графік сигналу від акселерометра при виконанні підтягувань До початку вправи значення прискорення по осі Y дорівнює - 1g. Перед першим підняттям корпусу вгору над перекладиною прискорення різко зменшується приблизно до — 1.6g, і потім збільшується приблизно до — 0.4g. При наступних трьох повтореннях спостерігається приблизно такий же характер вихідного сигналу, але без початкового падіння.

Через високу частоту опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного сигналу. Деякі стрибки амплітуд пов’язані з самим рухом корпусу, але вони також не сильно спотворюють форму вихідного сигналу.

Таким чином, можна зробити висновок, що для реєстрації початку вправи треба простежити перше падіння прискорення — 1g до приблизно — 1.5g. Значення можна узяти із запасом < - 1.3g. Для реєстрації кожного повторення необхідно виділити послідовність двох рухів — вгору-вниз. Рух вгору визначається по стрибку прискорення > - 0.7g, рух вниз — по падінню прискорення нижче — 1.3g. Усі значення прискорення беруться з невеликим запасом приблизно 10%, з урахуванням того, що кожна людина виконує вправу з різною силою і швидкістю.

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

Графік сигналу від акселерометра при виконанні віджимань

При виконанні віджимань значення прискорення по осях X і Y не сильно відхиляються від початкового положення. Найбільш зручною для реєстрації повторень є вісь Z.

До початку вправи значення прискорення по осі Z дорівнює - 1g. Перед першим опусканням корпусу вниз прискорення різко збільшується приблизно до — 0.4g, і потім зменшується приблизно до — 2.3g. При наступних чотирьох повтореннях спостерігається приблизно такий же характер вихідного сигналу.

Через високу частоту опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного сигналу. Деякі стрибки амплітуд пов’язані з самим рухом корпусу, але вони також не сильно спотворюють форму вихідного сигналу.

Таким чином, можна зробити висновок, що для реєстрації початку вправи треба простежити перше збільшення прискорення — 1g до приблизно — 0.4g. Значення можна узяти із запасом > - 0.7g. Для реєстрації кожного повторення необхідно виділити послідовність двох рухів — вниз-вгору. Рух вниз визначається по падінню прискорення нижче — 1.3g, рух вгору — по стрибку прискорення вище — 0.7g. Усі значення прискорення беруться з невеликим запасом приблизно 10%, з урахуванням того, що кожна людина виконує вправу з різною силою і швидкістю.

Далі необхідно провести дослідження сигналу від акселерометра при виконанні віджимань на брусах.

При виконанні віджимань на брусах значення прискорення по осях X і Z не сильно відхиляються від початкового положення. Найбільш зручною для реєстрації повторень є вісь Y.

До початку вправи значення прискорення по осі Y дорівнює - 1g. Перед першим опусканням корпусу вниз прискорення різко збільшується приблизно до — 0.6g, і потім зменшується приблизно до — 2.2g. При наступних чотирьох повтореннях спостерігається приблизно такий же характер вихідного сигналу.

Через високу частоту опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного сигналу. Деякі стрибки амплітуд пов’язані з самим рухом корпусу, але вони також не сильно спотворюють форму вихідного сигналу.

Графік сигналу від акселерометра при виконанні віджимань на брусах Таким чином, можна зробити висновок, що для реєстрації початку вправи треба простежити перше збільшення прискорення — 1g до приблизно — 0.6g. Значення можна узяти із запасом > - 0.7g. Для реєстрації кожного повторення необхідно виділити послідовність двох рухів — вниз-вгору. Рух вниз визначається по падінню прискорення нижче — 1.3g, рух вгору — по стрибку прискорення вище — 0.7g. Усі значення прискорення беруться з невеликим запасом приблизно 10%, з урахуванням того, що кожна людина виконує вправу з різною силою і швидкістю.

Далі необхідно провести дослідження сигналу від акселерометра при виконанні присідань. Графік приведений на рисунку 2.8.

При виконанні присідань значення прискорення по осях X і Z не сильно відхиляються від початкового положення. Найбільш зручною для реєстрації повторень є вісь Y.

Графік сигналу від акселерометра при виконанні присідань До початку вправи значення прискорення по осі Y дорівнює - 1g. Перед першим опусканням корпусу вниз прискорення різко збільшується приблизно до — 0.6g, і потім зменшується приблизно до — 2.4g. При наступних двох повтореннях спостерігається приблизно такий же характер вихідного сигналу.

Через високу частоту опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного сигналу. Деякі стрибки амплітуд пов’язані з самим рухом корпусу, але вони також не сильно спотворюють форму вихідного сигналу.

Таким чином, можна зробити висновок, що для реєстрації початку вправи треба простежити перше збільшення прискорення — 1g до приблизно — 0.6g. Значення можна узяти із запасом > - 0.7g. Для реєстрації кожного повторення необхідно виділити послідовність двох рухів — вниз-вгору. Рух вниз визначається по падінню прискорення нижче — 1.3g, рух вгору — по стрибку прискорення вище — 0.7g. Усі значення прискорення беруться з невеликим запасом приблизно 10%, з урахуванням того, що кожна людина виконує вправу з різною силою і швидкістю.

Останньою стандартною вправою є скручування.

Графік сигналу від акселерометра при виконанні скручувань При виконанні скручувань найбільш зручною для реєстрації повторень є вісь Z.

До початку вправи значення прискорення по осі Z дорівнює 1g. Перед першим підняттям корпусу прискорення різко збільшується приблизно до +1.6g, і потім зменшується приблизно до — 1g. При наступних двох повтореннях спостерігається приблизно такий же характер вихідного сигналу.

Через високу частоту опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного сигналу. Деякі стрибки амплітуд пов’язані з самим рухом корпусу, але вони також не сильно спотворюють форму вихідного сигналу.

Таким чином, можна зробити висновок, що для реєстрації початку вправи треба простежити перше збільшення прискорення від +1g до приблизно +1.6g. Значення можна узяти із запасом > +1.3g. Для реєстрації кожного повторення необхідно виділити послідовність двох рухів — вгору-вниз. Рух вгору визначається по падінню прискорення нижче 0.7g, рух вниз — по стрибку прискорення вище +1.3g. Усі значення прискорення беруться з великим запасом (запас при скручуваннях можна було зробити меншим), з урахуванням того, що кожна людина виконує вправу з різною силою і швидкістю і з урахуванням відповідності іншим вправам.

Оскільки смартфон може знаходитися в руках або кишені користувача в шести різних орієнтаціях (Portrait Up, Portrait Down, Landscape Right, Landscape Left, Face Up, Face Down), то і реєстрація повторень може проводитися за допомогою різних осей — X, Y або Z. Значення прискорень в різних орієнтаціях ніяк не відрізняються по амплітуді і частоті. Визначальним в підрахунку повторень є чинник вибору орієнтації, а отже і осі.

Як можна переконатися з усіх досліджених вправ, характер сигналу в усіх випадках практично однаковий. Значення амплітуд відрізняються трохи. Для кожної вправи рух вниз і вгору можна визначити як відхилення амплітуди прискорення від початкового значення на +0.3g.

Якщо положення смартфону відрізняється від усіх стандартних орієнтацій в просторі, і початкові значення по усіх осях приміром прагнуть по модулю до 0.5g, то погрішність є не критичною і близько 95% повторень реєструються. Єдиною перешкодою для правильної реєстрації повторень є погана фіксація смартфону в кишені або руках. Якщо користувач під час виконання вправи якось повертає або трясе iPhone, це може бути зараховано за зайві повторення.

Також на практиці слід досліджувати неправильне повторення вправ, тобто виконання вправ не в повну силу.

Графік сигналу від акселерометра при неправильному виконанні віджимань на брусах При неправильному виконанні вправ відхилення амплітуди прискорення по модулю становить менше ніж 0.3g. Таким чином це можна врахувати в організації алгоритму і не зараховувати неправильне виконання вправ.

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

Кожні 50 мс поступають нові значення від акселерометра. Якщо значення по вибраній осі відрізняється від початкового більш ніж на 0.3g, це прискорення реєструється як рух вгору або вниз. Якщо перший рух був вгору, то після появи руху вниз лічильник кількості повторень збільшується на 1. Якщо перший рух був вниз, то після появи руху вгору лічильник кількості повторень збільшується на 1. Підрахунок повторень триває, поки тривають нові рухи. Якщо по події п’яти секунд не було жодного руху, підрахунок зупиняється.

Для зручності користувача початок і кінець вправи супроводжуються звуковим сигналом. Існує безліч звукових бібліотек з різними функціональними можливостями. У проекті SportDiary використовується бібліотека AVFoundation.

Фрагмент початкового коду алгоритму автоматичного підрахунку вправ включений в опис класу TrainingViewController і приведений в додатку А.

2.3 Розробка кінцевої версії мобільного додатку і огляд використаних технологій

Розробка iPhone-додатків повинна проводитись на комп’ютерах сімейства Macintosh в середовищі розроблення програмного забезпечення XCode. У рамках магістерської роботи використовується версія XCode 4.

Пакет XCode підтримує мови програмування C, C++, Objective-C, Objective-C++, Java, AppleScript, Python та Ruby з різними моделями програмування. Для розробки проекту SportDiary використовується тільки Objective-C, оскільки він є стандартною мовою програмування для розробки додатків під iPhone.

Objective-C — підмножина С — є об'єктно-орієнтованою мовою програмування корпорації Apple. Основною відмінністю Objective-C є концепція відправлення повідомлень об'єктам, на що об'єкт відповідає виконанням певних дій. Для прикладу можна привести графічний інтерфейс, коли головний контролер відправляє повідомлення View нарисувати коло певного розміру, на що View рисує коло. Objective-C підтримує всі оператори мови С та білшість концепцій об'єктно-орієнтованого програмування.

Програма XCode призначена для розробки додатків для OS X (операційна система для комп’ютерів сімейства Macintosh), та iOS (операційна система для iPad, iPhone і iPod touch) і включає в себе низку інструментів для розробки програмного забезпечення, таких як документація розробника, додаток, що використовується для розробки графічних інтерфейсів, пакет моніторингу, та інші.

Операційні системи OS X та iOS архітектурно дуже схожі, за відміною того, що в ОС для смартфонів верхнім шаром є Cocoa Touch Framework, а в OS X — Cocoa Framework.

Загальна архітектура операційних систем Mac OS X та iPhone OS

Оскільки проект розроблюється для iPhone, далі буде розглядатися тільки архітектура iOS.

Нинжній рівень Core OS є фундаментом операційної системи. Він відповідає за організацію пам’яті, файлову систему, мережі та інші задачі, відповідні за апаратне забезпечення. Core OS складається з наступних компонентів:

— ядро OS X;

— Mach 3.0;

— BSD;

— сокети;

— рівень захисту;

— управління потужністю;

— Keychain;

— сертифікати;

— файлова система;

— Bonjour.

Наступний рівень Core Services є абстракцією над нижнім рівнем. Він забезпечує базовий доступ до сервісів iOS та включає наступні компоненти:

— колекції;

— адресна книга;

— мережі;

— доступ до файлів;

— SQLite;

— Core Location;

— веб-сервіси;

— потоки;

— Preferences;

— URL-утіліти.

Рівень Media забезпечує мультимедійні сервіси, що можна використовувати в додатках для iPhone та iPad. Він складається з наступних компонентів:

— Core Audio;

— OpenGL;

— Audio Mixing;

— аудіозапис;

— програш відео;

— JPG, PNG, TIFF;

— PDF;

— Quartz;

— Core Animation;

— OpenGL ES.

Рівень Cocoa Touch являє собою абстрактний шар, що представляє різноманітні бібліотеки для програмування iPhone та iPad, такі як наступні:

— події Multi-Touch;

— контроль Multi-Touch;

— акселерометр;

— ієрархія View;

— локалізація;

— сигнали;

— Web Views;

— People Picker;

— Image Picker;

— контролери.

У програмуванні iOS усі функції на кожному з рівнів забезпечуються за допомогою низки бібліотек. У проекті SportDiary використовуються усі рівні окрім нижчого.

Проект SportDiary розроблюється в пакеті розроблення програмного забезпечення XCode 4 в операційній системі Mac OS Lion.

Програма написана згідно зі схемою проектування MVC (model-view-controller), тобто модель-представлення-контролер.

Згідно з концепцією MVC програмний продукт повинен складатися з трьох компонентів: контролеру, представлення та моделі. Представлення — це графічний вид, тобто інтерфейс програми. Модель — це абстрактне представлення даних. Контролер — компонент який здійснює комунікацію між цими двома компонентами та оброблює необхідні дані.

Концепція проектування Model-View-Controller

Програмний продукт взаємодіє із користувачем через контролер. Додаток також взаємодіє з базою даних через абстрактну модель.

Отже розроблений проект SportDiary складається з наступних компонентів:

1. Графічний інтерфейс (приклад одного View приведений на рисунку 2.14). Графічний інтерфейс збудований згідно з рекомендаціями компанії Apple та є зручним та зрозумілим у використанні.

2. Контролер для кожного View.

3. Локальна база даних, в якій зберігаються статистичні дані та деякі дані користувача.

4. Модель, в якості якої використовуються встроєні в бібліотеку libsqlite3 функції.

Приклад View з проекту SportDiary

Головними компонентами програми є:

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

2. Складання статистики по кожній вправі та зберігання значень в базі даних SQLite. Відбудовування графіку статистики по кожній вправі (рисунок 2.15).

Статистика складається за наступним принципом. Усі повторювання вправи за день сумуються та зберігаються до бази даних. Якщо значення за сьогоднішній день вже зберігається в базі даних, то нове значення додається до попередньго і новий результат зберігається до бази даних. Коли користувач переходить до View, на якому представлений графік статистики, із бази даних вибираються значення для цієї вправи за кожен день та будується графік, кожна точка в якому представляє кількість повторювань вправи за один день. Статистика представляється за весь період тренувань. Якщо користувач взагалі не виконував цієї вправи, графік пустий.

Рисунок 2.15 — Графік статистики по обраній вправі

3. Синхронізація даних статистики та користувача з сервером. Для цього використовуються вбудовані функції роботи з URL для організації post та get-запросів.

На сервері були створені спеціальні API для взаємодії із додатком смартфону. Наприклад, для отримання кількості точок на графіку статистики з серверу необхідно сформувати строку запросу наступним чином:

NSString * request = [NSString stringWithFormat:@ «http://sportdiary.net/api/getchartdata_ios_counts.php? rand=%i&id=%@&caption_id=%@», num, userID, exerciseID].

Для тестування взаємодії програми із сервером проект був завантажений на iPhone 4 та протестований в локальному режимі та в режимі онлайн через Wi-Fi.

Проект являє собою сукупність View, пов’язаних один с одним за допомогою елементу Segue. Кожному View відповідає свій контролер. Статистика зберігається в базі даних, доступ до якої здійснюється за допомогою функцій бібліотеки libsqlite3.

Назви та призначення основних контролерів приведені в таблиці 2.1.

Таблиця 2.1 — Призначення основних контроллерів в проекті

При завантаженні додатка SportDiary з’являється стартове меню, з якого можна перейти на довідку Help або увійти до головної частини програми. Окрім цього стартовий вид (View) виконує функцію визначення наявності інтернету, а також початковій синхронізації.

Для перевірки наявності Інтернету на сервер вирушає get-запит, у відповідь на який приходить JSON-массив з єдиним параметром status, який оповіщає, був запит успішним або ні. Якщо у відповідь приходить значення 'ok ', то наявність Інтернету підтверджується. Якщо у відповідь приходить інше значення, або якщо у відповідь не приходить JSON масив, то додаток працюватиме в offline-режимі, оскільки немає Інтернету. Прапор наявності Інтернету зберігається в парі ключ-значення NSUserDefaults. Клас NSUserDefaults — простий спосіб зберігати базові значення, такі як об'єкти NSString, NSNumber, BOOL і т.д. [1]

Якщо це перша перевірка на наявність Інтернету і Інтернет доступний, проводиться реєстрація користувача в соціальній мережі. Для цього також використовується get — запрос за певною адресою, на що приходить відповідь у вигляді JSON-массива з полями login і password. Логін і пароль нового користувача зберігаються в базі даних на сервері.

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

Також можлива попередня синхронізація з сервером. Якщо в попередніх сеансах додаток працював в офлайн-режимі і будь-які дані були змінені, усі змінені дані будуть відправлені на сервер, якщо є підключення до Інтернету.

За допомогою Tab Bar додаток умовно розділений на 5 основних блоків:

1) Exercises — вправи і статистика користувача;

2) My Profile — основна інформація про користувача (ім'я, фотографія, логін і пароль для входу в соціальну мережу);

3) News — новини усіх користувачів і друзів;

4) People — список усіх користувачів, друзів, лідерів, а також елемент пошуку по користувачах;

5) Help — коротка довідка про використання додатка і деякі рекомендації по правильному виконанню вправ.

Статистичні дані і деякі дані про користувача зберігаються в локальній базі даних SQLite.

База даних називається ExercisesDB.sqlite. У базі зберігається три таблиці:

— Exercises — інформація про вправи;

— Statistics — інформація про статистику по вправах;

— Personal Data — персональні дані користувача.

Призначення полів в таблиці Exercises наступне:

— Name — назва вправи, зберігається у вигляді рядка;

— UniqueID — MD5-кодування імені вправи, зберігається у вигляді рядка. Використовується для зв’язку з таблицею Statistics і прискорення операцій з базою даних.

Призначення полів в таблиці Statistics наступне:

— Unique ID — кодування імені вправи, зберігається у вигляді рядка;

— ExerciseDate — остання дата виконання вправи, зберігається у вигляді рядка;

— Reps — кількість повторень вправ в певний день, зберігається у вигляді цілого числа.

Призначення полів в таблиці PersonalData:

— UserName — ім'я користувача, зберігається у вигляді рядка;

— UserLogin — логін користувача для входу в соціальну мережу, зберігається у вигляді рядка;

— UserPassword — пароль користувача для входу в соціальну мережу, зберігається у вигляді рядка;

— IsNameChanged — індикатор зміни імені користувача, потрібний для синхронізації, зберігається у вигляді цілого числа;

— IsPhotoChanged — індикатор зміни фотографії користувача, потрібний для синхронізації, зберігається у вигляді цілого числа;

— SyncDate — дата останньої синхронізації з сервером;

— UserID — ідентифікатор користувача, іншими словами, його порядковий номер реєстрації в соціальній мережі, зберігається у вигляді цілого числа.

У вкладці Exercises користувач може зайти в стандартні вправи, створити власні і видаляти вправи. При натисненні на будь-яку вправу, відкривається відповідна статистика.

Статистика може бути відредагована двома способами. Перший — виконати вправу з використанням автоматичного підрахунку вправи за допомогою вбудованого акселерометра. Другий — відредагувати статистику вручну. Можна змінити кількість виконаних вправ за будь-який день. Якщо встановити значення 0, це значення віддалиться з бази даних. Інтерфейс редагування статистики приведений на рисунку 2.18.

При кожному новому редагуванні бази даних змінені дані відразу ж відправляються на сервер. Таким чином усі зміни можна поспостерігати на сайті протягом декількох секунд. Якщо Інтернету в даний момент немає, то усі дані заносяться тільки в локальну базу даних і зводиться прапор необхідності синхронізації, який зберігається в стандартних налаштуваннях додатка. Коли Інтернет доступний і цей прапор дорівнює одиниці, відбувається синхронізація з сервером. Таким чином забезпечується збереження даних, і усі дані у будь-якому випадку синхронізуються з сервером, навіть якщо користуватися додатком в офлайн-режиме довгий час.

Інтерфейс редагування статистики Усі дані відправляються на сервер за допомогою POST-запиту. Нижче приведений фрагмент програмного коду відправлення даних на сервер за допомогою POST-запиту:

NSData *postData = [params dataUsingEncoding: NSUTF8StringEncoding allowLossyConversion: NO];

NSString *postLength = [NSString stringWithFormat:@ «%d», [postData length]];

int num = rand ();

NSString * reqURl = [NSString stringWithFormat:@ «http://sportdiary.net/api/sync_d.php? rand=%i», num];

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL: [NSURL URLWithString: reqURl]

cachePolicy: NSURLRequestReloadIgnoringLocalCacheData

timeoutInterval:5.0];

[request setHTTPMethod:@ «POST"];

[request setValue: postLength forHTTPHeaderField:@ «Content-Length"];

[request setValue:@ «application /x-www-form-urlencoded» forHTTPHeaderField:@ «Content-Type"];

[request setHTTPBody: postData];

NSData *responseData = [NSURLConnection sendSynchronousRequest: request returningResponse: nil error: nil];

В об'єкті postData зберігаються статистичні дані, які були додані пізніше за останню дату синхронізації. Об'єкт responseData приймає відповідь від сервера у форматі JSON-масива. Якщо єдиний параметр status рівний 'ok ', то синхронізація вважається успішною і остання дата змінюється на сьогоднішню. Якщо ж відправка даних була з помилкою, то синхронізація відкладається на наступний раз.

Максимальний час очікування відповіді від сервера встановлюється рівним п’яти секундам. Це зроблено на випадок повільного Інтернету користувача. Проте дане значення узято з великим запасом. У 95% тестування програми відповідь складала не більше секунди. Лише у пікові моменти завантаження сервера під час тестування утілитою ab він міг наближатися до 3 секунд.

Додаток SportDiary також підтримує можливість використання соціальної мережі, для якої виділено три вкладки: My Profile, News, People.

У вкладці My Profile можна змінити свої ім'я і фотографію, які будуть видні іншим користувачам соціальної мережі. Також тут зображені логін і пароль, під якими можна зайти в мережу на сайті sportdiary.net.

Нове ім'я користувача заноситься в локальну базу даних, а також вирушає на сервер за допомогою GET-запросу.

Нове фото користувача може бути вибране тільки з фотографій, збережених в альбомі iPhone, і вирушає на сервер, на відміну від імені, за допомогою POST-запросу, оскільки об'єм даних набагато більший.

У вкладці People можна подивитися зареєстрованих в соціальній мережі користувачів. У свою чергу усі користувачі розділені на три підгрупи:

— All — усі зареєстровані користувачі;

— Favourites — друзі, на яких підписався користувач;

— Top — користувачі, які виконали найбільше повторень стандартної вправи за поточний день.

Інтерфейс новин соціальної мережі в мобільному додатку SportDiary

Вкладка News аналогічна. У ній відображуються останні новини від користувачів All і Favourites. Дані, якими заповнюється Table View отримується у форматі JSON-массива в результаті запиту до сервера. JSON-массив зберігає наступну інформацію по кожному користувачеві: id користувача, його ім'я і новину. Фотографія користувача в дрібному форматі 75*75 пікселів отримується за допомогою звичайного запиту за адресою, по якій зберігається це фото.

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

Тестування проекту на витоки пам’яті

Як видно із малюнку 3.6 в проекті немає витоків пам' яті. Іноді при виділенні пам' яті під рядка можуть бути витоки блоків пам' яті не більш ніж 200 байт, але сморід не мають ніякого впливу на правильність роботи програми, оскільки в операційній системі є менеджер автоматичного підрахунку посилань, який виправляє витоки незначного розміру. Коли об'єкт має бути знищений через обнулення його лічильника посилань, Objective-C автоматично відправляє об'єкту повідомлення dealloc і розробник не повинен за цим стежити.

3. Розробка специфічної соціальної мережі, призначеної для користувачів мобільного додатка Sportdiary

3.1 Налаштування сервера і огляд використаних технологій Для підтримки соціальної мережі з великою (у перспективі) кількістю користувачів необхідно вибрати потужний і надійний сервер, який здатний витримувати високе навантаження на ресурси — більше 1000 запитів за секунду.

Раніше в ході роботи над високонавантаженими веб-сервісами було розроблено три додатки для соціальних мереж, які набрали аудиторію 130 000 користувачів.

Спочатку для підтримки цих додатків використовувався VPS-сервер, наданий українським підприємством HostLife. Основні характеристики цього сервера:

— процесор: 900 Мгц;

— ОЗП: 1 Гб;

— жорсткий диск: 20 Гб;

— трафік необмежений;

— ціна 30 у.е.

Проте із зростанням аудиторії приблизно до 100 000, сервер перестав справлятися з навантаженням. Завантаження оперативної пам’яті і процесора були в межах 90−100%. Це дослідження проводилося за допомогою команди top.

Також за весь час використання сервера були збої праці до цілої години.

Тому було прийнято рішення знайти потужніший і надійніший сервер.

В якості нового сервера був вибраний Root-сервер EX 5, наданий німецькою компанією Hetzner, сервери якої знаходяться поблизу міста Гамбург. Основні характеристики цього сервера наступні:

— процесор: Intel® Core™ i7 — 920 Quad-Core;

— ОЗП: 24 GB DDR3 RAM;

— жорсткий диск: 1.5 Тб;

— трафік необмежений;

— ціна 76 у.е.

Співвідношення ціна-якість німецького сервера набагато кращі за український. Також компанія Hetzner надає дуже зручну функцію автоматичного сповіщення про збої по смс і e-mail.

Протягом одного дня усі веб-додатки були перенесені на новий сервер і при тій же аудиторії трохи більше 100 000 чоловік завантаження оперативної пам’яті і процесора при перевірці командою top склало близько 1%.

Графік залежності завантаження сервера від кількості користувачів веб-додатків Таким чином був зроблений висновок, що проект SportDiary на початковому етапі слід розмістити на сервері Hetzner. Оскільки сервер з легкістю обслуговує додатки для соціальних мереж з аудиторією 130 000, то й додаток SportDiary обслуговуватиметься ще простіше, оскільки запити до сервера в іграх соціальних мереж повинні відбуватися набагато частіше, ніж до спортивного щоденника.

В якості HTTP-сервера був встановлений nginx. Для обробки скриптів був використаний обробник PHP-FPM, що працює в режимі FastCGI.

РНР має вбудований зв’язок із багатьма системами баз даних, у тому числі і MySQL. Це дуже зручна і ефективна технологія.

Нижче приведені основні директиви, які використовувалися при розробці сайту sportdiary.net, і які прописані в конфігураційному файлі nginx:

— fastcgi_intercept_errors on | off — визначає, чи передавати клієнтові відповіді FastCGI-сервера з кодом більше або рівним 400, або ж перенаправляти їх на обробку nginx’у за допомогою директиви error_page. У конфігураційному файлі встановлено значення on;

— fastcgi_ignore_client_abort on | off — визначає, чи закривати з'єднання з FastCGI-сервером у разі, якщо клієнт закрив з'єднання, не дочекавшись відповіді. Встановлено значення off;

— fastcgi_connect_timeout час — задає таймаут для встановлення з'єднання з FastCGI-сервером. Необхідно мати на увазі, що цей таймаут зазвичай не може перевищувати 75 секунд. Встановлений в значення 60;

— fastcgi_send_timeout час — задає таймаут при передачі запиту FastCGI-серверу. Таймаут встановлюється не на усю передачу запиту, а тільки між двома операціями запису. Якщо після закінчення цього часу FastCGI-сервер не прийме нових даних, з'єднання закривається. Встановлений в значення 180;

— fastcgi_read_timeout час — задає таймаут при читанні відповіді FastCGI-сервера. Таймаут встановлюється не на усю передачу відповіді, а тільки між двома операціями читання. Якщо після закінчення цього часу FastCGI — сервер нічого не передасть, з'єднання закривається. Встановлений в значення 180;