МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

Харківський національний університет радіоелектроніки

Кафедра системотехніки

ЗВІТ
З ВИКОНАННЯ КОНТРОЛЬНОЇ РОБОТИ
дисципліни «Технології розробки корпоративних web-додатків»

на тему: розробка інформаційної системи «Планувальник програм тренувань

(індивідуальна тема)

Виконал
студент групи КНТ-19-5
(найменування групи)
Сусла В.О.
(прізвище, ім'я по батькові)

Перевірив
доцент кафедри СТ
Коваленко А.І.

Харків 2023
 РЕФЕРАТ

Робота містить: 69 сторінку, 25 рисунка, 1 таблиця, 1 додаток, 2

джерел.

БАЗА ДАНИХ, ІНФОРМАЦІЙНА СИСТЕМА, МОБІЛЬНИЙ

ДОДАТОК, СЕРВЕР, СУБД, MYSQL, REST API, SQL

Об'єктом досліджень курсового проекту є процес надання певних

послуг спортивним тренерам швидко та зручно складати індивідуальні
програми тренувань кожному своєму клієнту. У той же час їхні клієнти
мають можливість побачити свій план тренувань у зручному представлені та
відмічати статус виконання вправ.
Предметом досліджень курсового проекту є інформаційні технології і
програмні методи створення клієнтської і серверної частин інформаційної
системи, що дозволяють автоматизувати процес складання тренувань та
зміни статусу виконання вправ.
Мета досліджень: розробка клієнтської і серверної частин
інформаційної системи планувальнику програм тренувань.
Методи дослідження – системний підхід, методи структурного аналізу і
моделювання реляційних баз даних, методи проектування клієнт-серверних
додатків для Інтранет- та Інтернет-мереж, подієвого об'єктно-орієнтованого
програмування.
У роботі проведено аналіз предметної області, що належить до
діяльності спортивних тренерів. Для визначення та уточнення вимог до
розроблюваної ІС проведено функціональне моделювання (відповідно до
стандарту IDEF0), логічне і фізичне моделювання даних (відповідно до
стандарту IDEF1Х). Розроблено діаграми UML-моделі. Проведено
проектування клієнтської і серверної частин ІС планувальнику програм
тренувань. За результатами тестування проведено аналіз відповідності
розробленого програмного забезпечення ІС висунутим вимогам.
Галузь застосування – технічна підтримка послуг спортивних тренерів.
 ЗМІСТ

СКОРОЧЕННЯ ТА УМОВНІ ПОЗНАКИ.............................................................4

ВСТУП......................................................................................................................5
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ....................................................................7
1.1 Аналіз предметної області, яка визначає діяльність підприємства........7
1.2 Аналіз реалізованих систем-аналогів........................................................7
1.3 Постановка задачі........................................................................................8
2 РОЗРОБКА ВИМОГ ДО СИСТЕМИ................................................................10
2.1 Розробка системних вимог до системи....................................................10
2.2 Розробка функціональних вимог до системи..........................................10
2.3 Розробка моделі потоків даних системи..................................................18
2.4 Розробка вимог до інтерфейсу клієнтської частини системи................21
2.4.1 Розробка діаграми варіантів використання системи.....................21
2.4.2 Розробка діаграми класів системи...................................................22
2.4.3 Розробка діаграми послідовності дій системи...............................24
3 ОПИС ПРИЙНЯТИХ ПРОЕКТНИХ РІШЕНЬ................................................29
3.1 Опис архітектури розробленої системи...................................................29
3.2 Логічне й фізичне моделювання даних системи....................................29
3.3 Створення бази даних на платформі........................................................33
3.4 Опис розробленої карти сайту..................................................................35
3.5 Розробка програмної логіки серверної частини системи.......................37
3.5.1 Розробка тригерів..............................................................................37
3.5.2 Розробка збережених процедур (функцій).....................................40
3.6 Тестування (верифікація) розробленого програмного забезпечення
системи..............................................................................................................42
ВИСНОВКИ...........................................................................................................47
ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАННЯ.....................................................................48
ДОДАТОК А..........................................................................................................49
ПОСІБНИК КОРИСТУВАЧА..............................................................................49
 СКОРОЧЕННЯ ТА УМОВНІ ПОЗНАКИ

 БД – база даних;

Вправа – елементарні рухи, складені з них рухові дії і їх комплекси,
систематизовані в цілях фізичного розвитку;
ІС – інформаційна система;
Клієнт – особа, що тренується з певним тренером;
СУБД – система управління базами даних;
Тренер – особа, що має відповідну кваліфікацію та знання для
проведення тренувань, складання тренувальних програм та надання
консультацій своїм клієнтам;
 ВСТУП

Зараз по всьому світу з'явилася така тенденція, як спортивний спосіб

життя, правильне харчування тощо. Загалом можна звести ці поняття до
здорового способу життя. Здоровим зараз бути модно, тому величезна
кількість людей займаються спортом з ранку до вечора, і не тільки, щоб
схуднути, а щоб відчувати себе здоровим, спортивним, підтягнутим, мати
бадьорий дух і запас енергії на весь день.
Займатися спортом можна по-різному, але більша кількість людей
вважають за краще ходити в спортзал, тому як там, крім тренажерів, надають
можливість займатися з тренером. Крім того, що це зручно – це ще й вигідно,
тому що спортивний тренер – це не тільки людина, яка вигадує вправи для
виконання, але ще і стежить за тим, щоб все було правильно і коректно
виконано.
Однак, поширена така проблема – весь облік тренувань відбувається в
паперовому вигляді, що не є зручно. Тому і було прийнято рішення
розробити такий програмний продукт, який допоміг би як клієнтові, так і
тренеру, так і людині, яка тренується сама відчувати себе комфортно під час
тренування. Зокрема цього, розроблюване рішення дозволить вести
тренування та програми дистанційно, що стало дуже актуальним в останній
час, коли тренери та клієнти можуть знаходитись у різних країнах.
Найбільш ефективним способом тренувань є виконання спортивних
програм. Оскільки зараз багато повсякденних операцій здійснюється завдяки
мобільним пристроям, було б розумно створити мобільний додаток для
складання програм тренувань.
Що стосується автоматизації процесів складання програм тренувань та
відмітки статусу виконання вправ, можна сказати, що це величезний плюс
для будь-якої інформаційної системи. Це дозволятиме зберігати та
маніпулювати інформацією в електронному вигляді. Завдяки автоматизації,
процес зберігання інформації буде більш надійним та зручним, аніж
аналогічний в паперовому вигляді.
Таким чином, мета даної роботи полягає в проектуванні та створенні
серверної частини бази даних високонавантаженої інформаційної системи,
яка підходила б за всіма критеріями, а також забезпечувала б зручним, і
головне, простим функціоналом для будь-якого користувача системи.
Актуальність даної роботи полягає в поставленій меті – аналізу
предметної області, проектуванні бази даних та можливість реалізувати
інформаційну систему в якості зручного та корисного додатка.
 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ.

1.1 Аналіз предметної області, яка визначає діяльність

підприємства

Зараз все більше різних сфер нашого життя переходять у світ

інформаційних технологій, які роблять вирішення повсякденних задач
легшим. Спорт та здоровий спосіб життя не стає виключенням. Зараз все
популярнішими стають різноманітні додатки для ведення тренувань,
моніторингу щоденної активності, тощо. Розглянемо як наразі відбувається
планування тренувань із тренерами.
Наразі маємо випадки, коли процеси взаємодії тренерів з їх клієнтами
взагалі не автоматизовані. Тренери опитують своїх клієнтів про їхні цілі та
побажання та на основі цього складають відповідні програми тренувань.
Розклад тренувань тренери зазвичай пишуть у блокнотах. Клієнти,
виконуючи вправи у залі ходять з цим блокнотом та ручкою та ведуть облік
виконання вправ. Тренери дивляться на те, як їхні клієнти виконують вправи,
на їхній прогрес, та потім на основі цих даних складають подальші плани
тренувань.
План тренувань складається із необхідних для виконання вправ у
зазначені дні задля досягнення певної мети (схуднення, підтримка фізичної
форми, тощо). Програма тренувань являє собою вправи, розписані за днями.
На певний день вправи можуть бути підібрані або на одну чи декілька груп
м’язів або одразу на всі групи м’язів (загальні тренування). Кожна вправа
складається з кількості підходів та повторень, діапазону робочої ваги.
Зокрема, може вказуватися час під навантаженням та деякі зауваження щодо
виконання.
 1.2 Аналіз реалізованих систем-аналогів

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

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

1.3 Постановка задачі

Необхідно розробити інформаційну систему з автоматизації процесів

складання плану спортивних тренувань та зміни статусу виконаної вправи.
Під час аналізу використання бізнес-функцій, що підлягають
автоматизації, було визначено відносно осіб, які працюватимуть з
Тренер підбирає та складає відповідну тренувальну програму,
враховуючі цілі, побажання та фізичну підготовку клієнта. Зокрема цього,
тренер повинен також враховувати наявність доступних тренажерів та
обладнання в залі.
Клієнт виконує вправи у назначені дні та записує як він із ними
впорався, чи важко йому було. Тренер слідкує за прогресом та має змогу
проаналізувати отриману інформацію від клієнта. Відштовхуючись від
всього цього тренер коригує та складає найбільш оптимальний план
тренувань для кожного клієнта індивідуально.
 2 РОЗРОБКА ВИМОГ ДО СИСТЕМИ

2.1 Розробка системних вимог до системи

Для нормальної роботи мобільного застосунку потрібно

притримуватись мінімальних вимог:
˗ Мінімальна версія ОС - Android 7.0 та новіші версії
˗ Оперативна пам'ять - 2 ГБ
˗ Сховище - 32 ГБ
˗ Частота процесора -1,4 ГГц
˗ Час роботи від батареї - Від 8 годин (в активному режимі)
˗ Архітектура - 64-бітна

2.2 Розробка функціональних вимог до системи

Основними процесами даної інформаційної системи, які необхідно

автоматизувати, є складання спортивної програми тренувань, (розклад самих
тренувань, їх тип та вправи у тренуванні), відмітка статусу виконання вправ.
Завдяки автоматизації цих процесів користувачі можуть швидко та зручно
складати розклад тренувань для себе, а тренери також і для кожного свого
клієнта, слідкувати за активністю протягом дня. Користувачі, можуть зручно
фіксувати виконання ним вправ, активність, тощо.
Бізнес-функції для неавторизованих та незареєстрованих користувачів:
– реєстрація;
– авторизація.
Бізнес-функції для тренерів:
– складання тренувальних програм (створення нового тренування на
обрану дату та створення вправ для заданого тренування);
– можливість відстежувати прогрес по кожній окремій вправі;
 – можливість відстежувати час виконання кожного тренування та
вправи;
– можливість стежити за статусом виконання тренувань;
– можливість бачити час виконання тренувань та вправ.
Бізнес-функції для клієнтів тренерів:
– заповнення інформації по виконаним підходам для кожної вправи;
– можливість відстежувати прогрес по кожній окремій вправі;
– можливість відстежувати час виконання кожного тренування та
вправи;
– можливість бачити подальшу програму тренувань.
Функціональні вимоги до системи визначають завдяки
функціональному моделюванню за методологією IDEF0. Діаграми
функціональної моделі являють собою прямокутники, що є функціями та
стрілки, що їх поєднують. Є чотири види стрілок: Вхід, вихід, керування та
механізм. Далі наведено контекстну діаграму та її декомпозиції.
На рисунку 2.1 зображено контексту діаграму.
 Рисунок 2.1 – Контекстна діаграма

Метою даної моделі, що зазначена на концептуальній діаграмі є

виявлення функцій, що належать автоматизації під час складання програм
тренувань та обліку їх виконання. Точкою зору є тренер. Діаграми
відповідають моделі «to be», яка передбачає створення програмного засобу
для виконання та автоматизації певних задач.
На концептуальній діаграмі зображена головна функція системи
«Складати програми тренувань, вести облік їх виконання, вести облік
користувачів». У якості механізмів виступають користувачі та програмне
забезпечення (ПЗ). Тут користувачами є всі особи, що користуються даним
рішенням. На вхід надходять особисті дані клієнта та тренера (такі як ім’я,
прізвище, контактні дані), дані для авторизації та цілі і побажання клієнтів.
Основна функція керується робочими обов’язками тренера, правами та
обов’язками клієнтів та наявністю тренажерів і необхідного обладнання. До
робочих обов’язків тренерів входить складати програми тренувань,
враховувати індивідуальні особливості клієнтів, слідкувати за фізичним
станом клієнтів. Права та обов’язки клієнта регламентується закладом у
якому тренується клієнт.
Основна задача поділяється на дві менші: «Вести облік користувачів»
та «Складати програми тренувань та вести облік їх виконання».
Декомпозиція контекстної діаграми зображена на рисунку 2.2

Рисунок 2.2 – Декомпозиція контекстної діаграми

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

Рисунок 2.3 – Декомпозиція функції «Вести облік користувачів»

Функція «Вести облік користувачів» складається з наступних задач:

«Зареєструватися в системі», «Авторизуватися, аутентифікуватися», «Вести
облік тренерів та їх клієнтів». Першу роботу виконують клієнти та ПЗ, на
вхід надходять дані про користувачів (клієнтів та тренерів). Результатом
роботи функції є інформація про зареєстрованих користувачів (логін, роль,
прізвище, ім’я та інш.), що є входом для другої функції та зареєстровані
користувачі, що є механізмом другої функції. Також у другої функції є ще
один механізм – ПЗ та ще один вхід – дані для авторизації. Робота
«Авторизуватися, аутентифікуватися» полягає в тому, щоб перевірити чи є
користувач дійсно зареєстрованим у системі та наданні йому певних прав та
можливостей в залежності від ролі користувача. Результатом роботи цієї
роботи є авторизовані та аутентифіковані користувачі, що є виходом та
механізмом для функції «Вести облік клієнтів та їх тренерів», та інформація
про авторизованих користувачів. Авторизовані та аутентифіковані
користувачі вже визначені системою тренери та клієнти, а інформація про
авторизованих користувачів являє собою деякі реквізити, що дозволяють
системі в залежності від ролі користувача визначати його можливості. Ще
одним механізмом третьої функції є ПЗ. Її суть полягає в тому, щоб
визначити клієнтів кожного тренера. Результатом роботи її є інформація про
клієнтів та їх тренерів (тобто тренер може побачити всіх своїх клієнтів та
навпаки). Ця інформація є частиною інформації про авторизованих
користувачів.
Робота з обліку тренерів та їх клієнтів складається з функцій «Зробити
запит на підтвердження, що користувач є клієнтом даного тренера» та
«Підтвердити або відхилити запит». Це зображено на рисунку 4.
 Рисунок 2.4 – Декомпозиція функції «Вести облік клієнтів та їх тренерів»

Першу функцію виконують авторизований клієнт та ПЗ, на вхід

надходить інформація про авторизованих користувачів. Результатом роботи є
сам запит, що надходить на вхід другій функції. Другу ж функцію виконує
авторизованій тренер та ПЗ. У разі відхилення запиту результатом роботи є
відхилений запит та в разі його підтвердження результатом є інформація про
клієнтів та їх тренерів.
Функцією, яка містить основний бізнес-процес даної задачі є
«Складати програми тренувань, вести облік їх виконань». Декомпозицію
даної роботи наведено на рисунку 5.

Рисунок 2.5 – Декомпозиція функції «Складати плани тренувань, вести облік

їх виконання»
 Функція «Складати програми тренувань та вести облік їх виконання»
складається з наступних задач: «Складати плани тренувань, вести облік їх
виконання», «Виконати вправи», «Ввести дані про виконані вправи». Першу
роботу виконують тренери, що є авторизованими та аутентифікованими
користувачами та ПЗ. При цьому тренером обробляються та враховуються
цілі та побажання клієнтів. Регламентують роботу цієї функції інформація
про тренера, що є інформацією про авторизованих користувачів, робочі
обов’язки тренера та наявність тренажерів/обладнання. Результатом роботи є
тренувальна програма, що складається зі списку тренувань та списку вправ
для кожного тренування. Роботу з виконання вправ виконують клієнти, що є
також авторизованими та аутентифікованими користувачами,
регламентуючись тренувальною програмою, правами та обов’язками клієнтів
та наявністю тренажерів/обладнання.

Результатом виконання вправ є дані про ці виконані вправи, що йдуть

на обробку функції «Внести дані про виконані вправи». Цю роботу
виконують клієнти та ПЗ. Результатом роботи є інформація про виконання
вправ, що надходить на вхід функції «Складати плани тренувань та вести
облік їх виконання» та обробляється при подальшому складанні програм.

На рисунку 2.6 зображено діаграму дерева вузлів.

 Рисунок 2.6 – Діаграма дерева вузлів

2.3 Розробка моделі потоків даних системи

У ході аналізу предметної області було також розроблено діаграма

потоків даних. Метою даної діаграми є визначення вимог до складу бази
даних для складання програм тренувань та обліку їх виконання. Точкою зору
також є тренер.
У даній діаграмі визначено зовнішні функції, основні таблиці, що
мають міститися у БД та потоки інформації. Контекстна діаграма потоків
даних зображена на рисунку 2.7.
 Рисунок 2.7 – Контекстна DFD-діаграма

Було виділено 3 зовнішніх сутності: тренер, клієнт та

незареєстрований/неавторизований користувач. В центрі діаграми зображено
головну функцію системи. Дані, що надходять від користувачів це дані для
авторизації, особисті дані клієнта і тренера та цілі і побажання клієнта. Від
системи до сутностей у свою чергу надходять дані, що містять списки
тренувань, списки вправ та інформація про виконання програми тренувань.
Далі цю діаграму було декомпозовано на три функції. Декомпозицію
контекстної DFD-діаграми зображено на рисунку 8.
 Рисунок 2.8 – Декомпозиція контекстної DFD-діаграми

На декомпозиції можна побачити три функції: «Вести облік

користувачів», «Складати плани тренувань, вести облік їх виконання» та
«Внести дані про виконані вправи». Було визначено 5 таблиць бази даних:
client, trainer, workout, exercise, completed_sets. Особисті дані користувачів та
дані для авторизації надходять до функції «Вести облік користувачів». Ця
функція у свою чергу звертається для читання та запису до таблиць client та
trainer. До функції «Складати плани тренувань, вести облік їх виконання»
надходить інформація про цілі та побажання клієнта. Дана функція
звертається до таблиць workout та exercise для читання та запису та до
таблиці completed_sets для читання. На вихід з цієї функції надходять списки
тренувань та вправ. Функція «Внести дані про виконані вправи» звертається
до таблиці completed_sets для запису та на вихід з неї надходить інформація
про виконання вправ.
 В таблиці trainer міститься інформація про тренерів, а саме: id, ім’я,
фамілія, логін, пароль, номер телефону та електрона пошта. Таблиця client,
що містить дані про клієнтів тренерів містить усі ті самі поля, що й таблиця
trainer, та містить ще одне додаткове поле: id тренера.
Таблиця workout зберігає інформацію про вправи. Дана таблиця
містить тип тренування, дату та id клієнта. Таблиця exercise містить дані про
вправи до тренувань, а саме: назву, кількість підходів, кількість повторень
від і до, додаткова вага від і до, час виконання вправи, примітки та id
тренування. Таблиця completed_sets зберігає виконані клієнтом підходи до
кожної вправи. Таблиця містить наступні поля: номер підходу, кількість
повторень, додаткова вага, час виконання, примітки, та id вправи.

2.4 Розробка вимог до інтерфейсу клієнтської частини системи

2.4.1 Розробка діаграми варіантів використання системи

На даному етапі було розроблено діаграму прецедентів, що відображає

можливі варіанти використання даної інформаційної системи. Акторами тут є
гості, що є неавторизованими користувачами, та тренери з клієнтами.
Діаграму прецедентів зображено на рисунку 2.9.
Як можна побачити, неавторизованим користувачам доступні лише два
варіанти використання: авторизація та реєстрація. Як і було вказано у
дослідженні предметної області, тренери можуть переглядати та створювати
програми тренувань. Створення програми тренувань включає у себе вибір
дати та типу тренування, та додавання вправ до тренування. Зокрема цього,
тренер може подивитись як його клієнти виконали назначені ним вправи. І,
як було сказано раніше, клієнти можуть прийняти, або відхилити запит від
користувача, що авторизувався у ролі клієнта.
Клієнт же може відправити запит тренеру, дивитись свій план
тренувань та вносити дані про виконані ним вправи.
 Рисунок 2.9 – Діаграма прецедентів

2.4.2 Розробка діаграми класів системи

На рисунку 2.10 зображено розроблену діаграму класів серверної

частини додатку. Серверна частина буде представлена у вигляді REST API та
для розробки буде використано мову програмування Kotlin та Spring
Framework. Було прийнято рішення використовувати архітектуру MVC із
поєднанням Clean Architecture Роберта Мартіна
Рисунок 2.10 – Діаграма класів серверної частини
 Клас User представляє собою тренерів та їх клієнтів. У даному випадку
між класом User та Workout зв’язок, як такий, не потрібен. Це обумовлюється
там, що ми будемо отримувати клієнтів та тренерів окремо від тренувань. Це
необхідно для того, щоб не завантажувати кожен раз величезний обсяг плану
тренувань, коли нам потрібен лише користувач. Тренування отримуються
окремо на відповідних сторінках інтерфейсу.
Між класом Workout та Exercise існує відношення композиції один до
багатьох. Це обумовлено тим, що у одного тренування є декілька вправ, та
вправи не можуть існувати окремо від тренувань. Аналогічна ситуація з
класами Exercise та Completed Set.
Додаток поділено на відповідні шари. Є шар DAO, що відповідає за
роботу з БД та взагалі за доступ до даних. Роботу з Dao класами інкапсолює в
собі репозиторій (інтерфейс TrainingRepository та його реалізація).
Репозиторій відповідає за логіку роботи з класами доступу до даних та
конвертацію сутностей доменного рівня до сутностей рівня даних та навпаки.
Наступний шар – це шар Interactors (або, більш звична назва - Service). Даний
шар відповідальний за всю бізнес-логіку додатку (валідація і т.д.). Як можна
побачити, кожний інтерактор містить у собі та використовує інтерфейс
репозиторію. І на найвищому рівні знаходиться шар контролерів, що
використовує інтерактори.

2.4.3 Розробка діаграми послідовності дій системи

Прецеденти «Назначити день та тип тренування», «Задати прави для

кожного з тренувань» та «Внести дані про виконані вправи» були
декомпозовані на діаграми послідовностей та кооперативні діаграми.
На рисунках 3-5 зображені діаграми послідовностей для прецедентів
«Назначити день та тип тренування», «Задати прави для кожного з
тренувань» та «Внести дані про виконані вправи» відповідно. На рисунках 5-
7 зображені відповідні їм діаграми кооперацій.
 Спочатку тренер вводить дані про тренування на відповідному вікні.
Далі створюється об’єкт «Тренування», що надсилається до відповідного
сервісу. Далі Сервіс проводить валідацію. Якщо валідація не пройшла, то
назад відсилається повідомлення про помилку. В іншому випадку тренування
надсилається у виді повідомлення до шару доступу до даних. Якщо
збереження пройшло успішно, то тренер бачить вікно з усіма тренуваннями,
у тому числі й щойно доданим. Якщо під час збереження трапилася помилка,
то назад відсилається повідомлення про помилку.
Решта діаграм мають аналогічну послідовність дій
Рисунок 2.11 – Діаграма послідовностей для прецеденту «Назначити день та тип тренування»
Рисунок 2.12 – Діаграма послідовностей для прецеденту «Задати прави для кожного з тренувань»
Рисунок 2.13 – Діаграма послідовностей для прецеденту «Внести дані про виконані вправи»
 29

3 ОПИС ПРИЙНЯТИХ ПРОЕКТНИХ РІШЕНЬ

3.1 Опис архітектури розробленої системи

Розроблювана інформаційна система є трьох-рівневою, тобто всю систему
можна поділити на три шари: шар бази даних, рівень серверної бізнес-логіки та
рівень клієнту.
На рівні клієнту функціонуватиме мобільний додаток для операційної
системи Android. Серверна частина буде реалізована за допомогою фреймворку
Spring. Серверна та клієнтські частини будуть реалізовані на сучасній мові
програмування Kotlin. На шарі БД використовуватиметься СУБД MySQL.

3.2 Логічне й фізичне моделювання даних системи

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

Рисунок 3.1 – Логічна модель даних

Жоден із зв’язків не допускає значення NULL для зовнішніх ключів окрім

зв’язку між клієнтом і тренером, на що вказує білий ромб на зв’язку зі сторони
тренера. Це допустимо так, як коли клієнт тільки реєструється в системі, йому не
може бути одразу призначений тренер, тому значення цього атрибуту буде NULL.
Можна побачити, що для деяких атрибутів встановлена унікальна ключова група,
а саме для атрибуту login тренера та клієнта. Також для атрибутів w_date таблиці
workout, t_name та surname таблиці мають також свої ключові групи. Для сутності
trainer ці ключи будуть використовуватися для пошуку, а для сутності workout для
сортування тренувань за датою.
У ході визначення функціональних вимог до системи було визначено, що
клієнти можуть робити запити до тренерів, а тренери підтверджувати або
відхиляти їх. Так як декілька різних клієнтів можуть зробити запит до тренера, і
декілька тренерів можуть мати запити від одного й того ж клієнта, то виникає
зв’язок багато до багатьох. Для його вирішення було створено таблицю request,
що й відображає запит.
 31

Сутність trainer відображає тренера. Усі атрибути даної сутності типу String,
тобто строки. Перелік атрибутів сутності:
– t_name – ім’я тренера;
– surname – фамілія тренера;
– login – логін тренера;
– t_password – пароль тренера;
– phone_number – номер телефону;
– email – електронна пошта.
Сутність client відображає клієнта тренера. Сутність містить наступні
атрибути:
– с_name – ім’я клієнта, тип String;
– surname – фамілія клієнта, тип String;
– login – логін клієнта, тип String;
– t_password – пароль клієнта, тип String;
– phone_number – номер телефону, тип String;
– email – електронна пошта, тип String;
– trainer_id – ідентифікатор тренера, що дозволяє визначити тренера клієнта.
Сутність request містить інформацію про запит від клієнта до тренера.
Сутність містить три атрибути:
– r_status – статус запиту (не визначено, прийнято, відхилено), тип
символьний рядок;
– client_id – ідентифікатор клієнта, число;
– trainer_id – ідентифікатор тренера, число.
Сутність workout містить інформацію про вправи. Сутність містить наступні
атрибути:
– w_type – відображає назву, тип тренування, тип символьний рядок;
– w_date – дата тренування, тип дата та час;
– client_id – ідентифікатор клієнта, число.
Сутність exercise зберігає інформацію про вправи у тренуванні. Дана
сутність містить наступні атрибути:
 32

– e_name – назва вправи, тип символьний рядок;

– sets – кількість підходів для виконання вправи, число;
– repetitions_from – початок діапазону кількості повторів, число;
– repetitions_to – кінець діапазону кількості повторів, число;
– weight_from – початок діапазону додаткового навантаження,
необов’язковий атрибут, число;
– weight_to – кінець діапазону додаткового навантаження, необов’язковий
атрибут, число;
– e_time – рекомендований час виконання вправи, необов’язковий атрибут,
тип дата та час;
– notes – примітки та рекомендації щодо виконання вправи, символьний
рядок;
– workout_id – ідентифікатор тренування, число.
Сутність completed_set містить інформацію про виконані підходи вправи. У
наявності є наступні атрибути:
– set_number – номер підходу, число;
– repetitions – фактична кількість виконаних підходів, число;
– weigth – фактичне додаткове навантаження для виконання вправи,
необов’язковий атрибут, число;
– c_time – фактичний час виконання вправи, необов’язковий атрибут, число;
– notes – примітки щодо виконання вправи, необов’язковий атрибут,
символьний рядок;
– exercise_id – ідентифікатор вправи, число.
Наступним етапом було проектування фізичної моделі бази даних. Фізичну
модуль даних зображено на рисунку 2. На етапі проектування фізичної моделі
було визначено типи даних атрибутів сутностей, чи можуть вони мати значення
NULL, правила цілісності даних та посилань.
 33

Рисунок 3.2– Фізична модель даних

Для зв’язку між тренером та клієнтом при видаленні тренера значення

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

3.3 Створення бази даних на платформі

За розробленими моделями даних було створено базу даних у СУБД

MySQL. EER-діаграма розробленої бази даних зображена на рисунку 3.
Далі нижче наведено правила посилальної цілісності у таблиці 1. За
замовчуванням СУБД MySQL підтримує посилальну цілісність для таблиць типу
InnoDB та встановлюється тип посилальної цілісності NO ACTION, що
еквівалентно RESTRICT. RESTRICT для дії UPDATE не дозволить оновити
первинний ключ головної таблиці, якщо на нього посилається запис у залежній
таблиці. Для DELETE СУБД не дозволить видалити запис у головній таблиці,
якщо на нього посилається запис у залежній таблиці. Також у СУБД MySQL існує
 34

такий тип посилальної цілісності, як CASCADE. Для дії UPDATE це означає, що

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

Рисунок 3.3 – EER-діаграма розробленої бази даних

Для коректної роботи у колекції trainers кожен документ повинен мати поле
name для імені, surname для фамілії, login для зберігання логіну, password пароль
для зберігання паролю, phoneNumber для зберігання номеру телефону (може
містити null), email для зберігання електронної пошти.
Документи у колекції clients повинні мати усі ті ж самі поля, що й у колекції
trainers, але ще має бути додаткове поле: trainerId, щоб можна було визначити хто
є тренером даної людини. Це поле має тип Number. Усі посилання на
ідентифікатори документів матимуть цей тип даних, бо він є більш універсальним
і у майбутньому міграція на реляційну БД буде значно простішою.
 35

Як було встановлено у ході аналізу предметної області, то клієнти у додатку

надсилають запити до свого тренера, щоб тренер додав людину до своїх клієнтів.
Для цього було створено колекцію requests. Кожен документ у цій колекції
матиме три поля: clientID, trainerId для ідентифікації тренера та клієнта, а також
поле status, що відображає статус запиту. Дане поле має тип String та може
приймати лише три значення: UNCHECKED, DECLINED, APPROVED.
Документи у колекції workouts повинні мати поле clientId для ідентифікації
клієнта, якому належить це тренування, date типу Number для зберігання дати
тренування та поле type для зберігання типу тренування, тип даних якого String.

Таблиця 3.1 – Правила посилальної цілісності для пов’язаних таблиць

№ Ім’я таблиці 1, Ім’я таблиці 2, SQL Тип
зовнішній ключ первинний ключ інструкція посилальної
1 таблиці цілісності
1 client, trainer_id trainer, id UPDATE RESTRICT
2 client, trainer_id trainer, id DELETE SET NULL

3 request, trainer_id trainer, id UPDATE RESTRICT

4 request, trainer_id trainer, id DELETE CASCADE
5 request, client_id client, id UPDATE RESTRICT
6 request, client _id client, id DELETE CASCADE

7 workout, client_id client, id UPDATE RESTRICT

8 workout, client_id client, id DELETE CASCADE
9 exercise, workout_id workout, id UPDATE RESTRICT
10 exercise, workout_id workout, id DELETE CASCADE
11 completed_sets, exercise, exercise_id UPDATE RESTRICT
exercise_id
12 completed_sets, exercise, exercise_id DELETE CASCADE
exercise_id

3.4 Опис розробленої карти сайту

Клієнтська частина корпоративної інформаційної системи представлена

мобільним застосуванням. Екрани застосування розподілені за ролями
 36

користувачів: анонімні користувачі, тренери та клієнти тренерів. Нижче наведено

перелік екранів з розмежуванням за ролями.
Екрани, доступні анонімним користувачам:
 екран авторизації;
 екран реєстрації.
Екрани, доступні тренерам:
 екран профілю користувача;
 екран зі списком клієнтів;
 екран профілю клієнта;
 екран зі списком програм тренувань для обраного клієнта;
 екран додавання та редагування тренування;
 екран зі списком вправ для обраного тренування;
 екран додавання та редагування вправи;
 екран зі списком виконаних підходів;
 екран зі списком запитів від клієнтів.
Екрани, доступні клієнтам тренерів:
 екран профілю користувача;
 екран профілю тренера;
 екран зі списком тренувань;
 екран зі списком вправ для обраного тренування;
 екран зі списком виконаних підходів;
 екран для додавання та редагування виконаного підходу;
 екран для пошуку тренера та створення запиту;
 екран зі списком створених запитів.
Карти навігації мобільного застосунку для тренера та клієнта зображено на
рисунках 6 та 7 відповідно.
 37

Рисунок 3.4 – Карта мобільного застосування для тренера

Рисунок 3.5 – Карта мобільного застосування для клієнта

Далі, у додатку А наведено керівництво користувача, у якому надано

інформацію щодо користування та умов використання застосунку.

3.5 Розробка програмної логіки серверної частини системи

3.5.1 Розробка тригерів

Розглянемо тригери для підтримання посилальної цілісності таблиці

workout. У тригерах, що спрацьовують перед вставкою та оновленням даних
перевіряється чи існує відповідний запис у таблиці client. Якщо такого запису не
 38

існує, то генерується помилка. У тригері, що спрацьовує після видалення запису з

таблиці workout видаляються усі записи з відповідним workout_id з таблиці
exercise. Код тригерів для таблиці workout зображено на лістингу 3.1.

Лістинг 3.1 – Тригери для таблиці workout

create trigger before_workout_insert before insert on workout for each row begin
if (not exists(select * from user where client.id = new.client_id)) then begin
signal sqlstate '45000' set mysql_errno = 30001, message_text = 'Can not insert this row,
check your ids';
end;
end if;
end;

create trigger before_workout_update before update on workout for each row begin
if (not exists(select * from user where client.id = new.client_id)) then begin
signal sqlstate '45000' set mysql_errno = 30001, message_text = 'Can not update this row,
check your ids';
end;
end if;
end;

create trigger after_workout_delete before delete on workout for each row begin
delete from exercise where exercise.workout_id = old.workout_id;
end;

Далі розглянемо тригери для підтримання посилальної цілісності таблиці

exercise. У тригерах, що спрацьовують перед вставкою та оновленням даних
перевіряється чи існує відповідний запис у таблиці workout. Якщо такого запису
не існує, то генерується помилка. У тригері, що спрацьовує після видалення
запису з таблиці exercise видаляються усі записи з відповідним exercise _id з
таблиці completed_sets. Код тригерів для таблиці workout зображено на лістингу
3.2.

Лістинг 3.2 – Тригери для таблиці exercise

create trigger before_exercise_insert before insert on exercise for each row begin
if (not exists(select * from workout where workout.id = new.workout_id)) then begin
signal sqlstate '45000' set mysql_errno = 30001, message_text = 'Can not insert this row,
check your ids';
 39
end;
end if;
end;

create trigger before_exercise_update before update on exercise for each row begin
if (not exists(select * from workout where workout.id = new.workout_id)) then begin
signal sqlstate '45000' set mysql_errno = 30001, message_text = 'Can not update this row,
check your ids';
end;
end if;
end;

create trigger after_exercise_delete before delete on exercise for each row begin
delete from completed_sets where completed_sets.exercise_id = old.exercise_id;
end;

Далі розглянемо тригери для підтримання посилальної цілісності таблиці

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

Лістинг 3.3 – Тригери для таблиці completed_sets

create trigger before_completed_sets_insert before insert on completed_sets for each row
begin
if (not exists(select * from exercise where exercise.id = new.exercise_id)) then begin
signal sqlstate '45000' set mysql_errno = 30001, message_text = 'Can not insert this row,
check your ids';
end;
end if;
end;

create trigger before_completed_sets_update before update on completed_sets for each row begin
if (not exists(select * from exercise where exercise.id = new.exercise_id)) then begin
signal sqlstate '45000' set mysql_errno = 30001, message_text = 'Can not update this row,
check your ids';
end;
end if;
end;

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

із бази даних (для подальшого аналізу, збору статистики та інш.) було розроблено
 40

тригер, що спрацьовує перед видаленням з таблиць trainer та client та генерує

помилку. Даний тригер зображено на лістингу 3.4.

Лістинг 3.4 – Тригери, що забороняють видалення записів з таблиць trainer

та client
create trigger before_trainer_delete before delete on trainer for each row begin
signal sqlstate '45000' set mysql_errno = 30001, message_text = 'This action is not allowed';
end;
create trigger before_client_delete before delete on client for each row begin
signal sqlstate '45000' set mysql_errno = 30001, message_text = 'This action is not allowed';
end;

Для реалізації функції «Підтвердження запиту від клієнта» також було

розроблено тригер, що автоматично встановлює відповідний trainer_id у
потрібному записі у таблиці client після того, як тренер підтвердив запит. Даний
тригер зображено на лістингу 3.5.

Лістинг 3.5 – Тригер, що автоматизує процес підтвердження запиту від

клієнта
create trigger after_request_update after update on request for each row begin
if (new.r_status = 'confirmed') then begin
update user set trainer_id = new.trainer_id where id = new.client_id;
end;
end if;

3.5.2 Розробка збережених процедур (функцій)

Для реалізації функції перевірки можливості оновлювати та додавати дані

таблиці workout було створено функцію, код якої наведено на лістингу 6. Дана
функція на вхід приймає ідентифікатор клієнта, для якого створюватиметься
тренування. Функція перевіряє, чи існує відповідний запис у таблиці client та
повертає числове значення 1 чи 0 (true чи false відповідно).
 41

Лістинг 3.6 – Функція перевірки можливості оновлювати та додавати дані

таблиці workout
create function can_create_or_update_workout(new_client_id integer) returns integer reads sql
data begin
return exists(select * from client where client.id = new_client_id);
end;

Для реалізації функції перевірки можливості оновлювати та додавати дані

таблиці exercise було створено функцію, код якої наведено на лістингу 3.7. Дана
функція на вхід приймає ідентифікатор тренування, для якого створюватиметься
вправа. Функція перевіряє, чи існує відповідний запис у таблиці workout та
повертає числове значення 1 чи 0 (true чи false відповідно).

Лістинг 3.7 – Функція перевірки можливості оновлювати та додавати дані

таблиці exercise
create function can_create_or_update_exercise(new_workout_id integer) returns integer reads
sql data begin
return exists(select * from workout where workout.id = new_workout_id);
end;

Для реалізації функції перевірки можливості оновлювати та додавати дані

таблиці completed_sets було створено функцію, код якої наведено на лістингу 3.8.
Дана функція на вхід приймає ідентифікатор вправи, для якого створюватиметься
виконаний підхід. Функція перевіряє, чи існує відповідний запис у таблиці
exercise та повертає числове значення 1 чи 0 (true чи false відповідно).

Лістинг 3.8 – Функція перевірки можливості оновлювати та додавати дані

таблиці completed_sets
create function can_create_or_update_completed_set(new_exercise_id integer) returns integer
reads sql data begin
return exists(select * from exercise where exercise.id = new_exercise_id);
end;
 42

Для відображення кількості клієнтів для конкретного тренера було

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

Лістинг 3.9 – Код процедури відображення кількості клієнтів для

конкретного тренера
create procedure display_number_of_clients_by_trainer_id(in trainer_id integer) begin
select count(*) from client where client.trainer_id = trainer_id;
end;

3.6 Тестування (верифікація) розробленого програмного забезпечення

системи

На даному етапі було проведено тестування клієнтської та серверної

частини. У ході тестування було перевірено всі функції. Розроблена ІС відповідає
всім висунутим вимогам та працює коректно. У разі помилки користувачу буде
надане відповідне повідомлення.
Для розробки самого проекту застосовувалась мова програмування Kotlin,
тому для Unit тестування було обрано використати Junit Framework. Тести також
створювалися на мові програмування Kotlin.
Також було проведено навантажувальне тестування БД. Load Test було
проведено за допомогою спеціального програмного забезпечення – Jmeter. Дане
програмне забезпечення було розроблено на мові програмування Java та може
застосовуватися для навантажувального тестування баз даних, REST API,
GraphQL запитів, запуску Java Unit Tests та багатьох інших задач.
Код модульного тесту зображено на рисунку 3.6. У даному класі тестується
WorkoutsInteractor, де перевіряється коректність роботи бізнес-логіки отримання,
додавання, редагування та видалення тренувань. Так як це модульний тест, і
тестується лише бізнес-логіка, то нам немає необхідності робити запити до бази
 43

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

роботи з DAO класами працює зі звичайними списками.
Як можна побачити, то на початку ініціалізуються репозиторій та сервіс
(інтерактор). Далі проводить тестування коректності роботи усіх методів
інтерактора завдяки assert методам фреймворка Junit.

Рисунок 3.6 – Модульний тест класу WorkoutsInteractor

На рисунку 3.7 зображено код тесту MySqlWorkoutsDaoImplTest, який

перевіряє коректність роботи усіх запитів до таблиці workout. Алгоритм
тестування дуже схожий на алгоритм тестування роботи бізнес-логіки інтерактора
з попереднього розділу. Для тесту було створено спеціальний тестовий
DBConnector, що далі передається в конструктор DAO класу. Даний конектор
повертає з’єднання зі спеціально створеною тестовою базою даних. Таке рішення
було прийнято для того, щоб не змішувати тестові дані з даними реальних
користувачів та зробити результати тестування більш стабільними.
 44

Рисунок 3.7 – Модульний тест бази даних класу MySqlWorkoutsDaoImpl

Результати модульного тестування бізнес-логіки та бази даних зображено на

рисунках 3.8 та 3.9 відповідно. Як можна побачити, усі тести виконані успішно,
що означає коректну роботи розробленої корпоративної інформаційної системи.

Рисунок 3.8 – Результат модульного тесту

 45

Рисунок 3.9 – Результат модульного тестування бази даних

На рисунках 3.10 – 3.13 зображено результати навантажувального

тестування бази даних. На рисунку 3.10 зображено результати та час виконання
5000 запитів у циклі з 10 повторень. Для запитів було налаштовано пул з 10
з’єднань. Як можна побачити, найдовший запит оброблявся трохи більше, ніж 17
секунд. Скоріш за все така затримка з’явилась через велику кількість одночасних
запитів. Найшвидший запит виконався майже миттєво. На рисунку 3.13
зображено результат SQL запиту, що тестується.

Рисунок 3.10 – Результат навантажувального тесту з найдовшими запитами

 46

Рисунок 3.11 – Результат навантажувального тесту з найшвидшими запитами

Рисунок 3.12 – Результат виконання SQL запиту, що тестується

Результат запиту є коректним.

 47

ВИСНОВКИ

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

планування розкладу тренувань.
Був детально описаний основний бізнес-процес, сформовані функціональні
вимоги, вимоги до клієнтської та серверної частин. Виконано пректування
системи.
У ході проектування були використані методології IDEF0, IDEF1X, мова
UML та відповідні CASE-засоби. Було розроблено функціональну модель, логічну
та фізичну моделі даних. Спроектовано UML діаграми класів, пречедентів,
послідовностей, діяльності та станів.
Наступним етапом була програмна реалізація та тестування. Було
обґрунтовано вибір мови програмування та СУБД для реалізації системи.
Створено базу даних, серверну частину у вигляді REST API та клієнтську частину
у вигляді мобільного додатку.
 48

ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАННЯ

1. ДСТУ 3008-2015. Документація. Звіти в сфері науки і техніки. Структура

і правила оформлювання. Чинний від 2017-07-01. – Київ : ДП «УкрНДНЦ», 2016.
– 26 с.;
2. ДСТУ 7.1:2006. Система стандартів з інформації, бібліотечної та
видавничої справи. Бібліографічний запис. Бібліографічний опис. Загальні
вимоги та правила складання / Нац. стандарт України. – Вид. офіц. – [Чинний від
2007-07-01]. – Київ : Держспоживстандарт України, 2007. – 47 с.;
 49

ДОДАТОК А

ПОСІБНИК КОРИСТУВАЧА
 МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ РАДІОЕЛЕКТРОНІКИ

Затверджую
Керівник роботи,
Доц. каф. СТ
А.І. Коваленко
(підпис, дата)

РОЗРОБКА КОМПОНЕНТІВ РЕКОМЕНДАЦІЙНОЇ СИСТЕМИ ПІДБОРУ

КОМП’ЮТЕРНОЇ ТЕХНІКИ

Керівництво користувача

Аркуш затвердження

ГЮІК. 505500.017 – ІЗ – ЛУ

Студент групи КНТ-19-5

(назва групи)

24.02.2023 Сусла В. О.
(підпис дата, прізвище, ім’я, по батькові)

2023
 51

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ РАДІОЕЛЕКТРОНІКИ

ЗАТВЕРДЖЕНО
ГЮІК. 505500.017 – ІЗ – ЛУ

РОЗРОБКА КОМПОНЕНТІВ РЕКОМЕНДАЦІЙНОЇ СИСТЕМИ ПІДБОРУ

КОМП’ЮТЕРНОЇ ТЕХНІКИ

Керівництво користувача

ГЮІК. 505500.017 – ІЗ – ЛУ

аркушів – 21

2023
 52

ЗМІСТ
Вступ………………………………………………………………………………..
1 ПРИЗНАЧЕННЯ І УМОВИ ВИКОРИСТАННЯ………………………………
1.1 Найменування застосування ……….………………………………………………………………………………
1.2 Область використання застосування ….…….…….………………………………………………………
1.3 Стислий опис можливостей застосування …….........................................................
1.4 Рівень підготовки користувача.…………………………………………………………………………………
1.5 Види діяльності, функції застосування …………………………………………………………………
1.6 Програмні та апаратні вимоги до застосування ………………………………………………..
2 ПІДГОТОВКА ДО РОБОТИ……………………………………………………
2.1 Встановлення програмного забезпечення web-застосування…………...
2.2 Запуск застосування ……………………………………………………………………………………………………….
2.3 Перевірка працездатності застосування ……………………………………………………………….
3 ОПИС ОПЕРАЦІЙ……………………………………………………………...
3.1 Операції для незареєстрованих та/або неавторизованих користувачів ….
3.1.1 Авторизація……………………………………………………………...
3.1.2 Реєстрація………………………………………………………………..
3.2 Операції для клієнтів та тренерів………………………………………….
3.2.1 Перегляд списку тренувань та його редагування ……………………………………….
3.2.2 Перегляд списку вправ та його редагування ………………………………………………..
3.2.3 Перегляд та редагування списку виконаних підходів вправи ………………
3.2.4 Пошук тренера та створення запиту …………………………………………………………………
3.2.5 Перегляд списку зроблених запитів для ролі клієнта ..……………………………..
3.2.6 Перегляд списку запитів від клієнтів для ролі тренера .……………………………
4 АВАРІЙНІ СИТУАЦІЇ…………………………………………………………...
5 РЕКОМЕНДАЦІЇ З ОСВОЄННЯ………………………………………………..
 53

ВСТУП

Дане програмне забезпечення може використовуватися спортивними

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

1. ПРИЗНАЧЕННЯ ТА УМОВИ ВИКОРИСТАННЯ

1.1 Найменування застосування
Інформаційна система «Планувальник програм тренувань».
1.2 Область використання застосування
Розроблене програмне забезпечення призначене для складання планів
тренувань тренерами та для фіксування виконання вправ клієнтами.
1.3 Стислий опис можливостей застосування
Клієнтська частина представлена у вигляді мобільного додатку, що
використовується для складання програм тренувань та ведення обліку їх
виконання. Для користування всіма функціями необхідно бути зареєстрованим та
авторизованим користувачем. Тренери можуть приймати запити від клієнтів,
складати програми тренувань (створювати тренування та вправи для них) та
слідкувати за прогресом клієнтів. Клієнти можуть переглядати створені тренером
тренування та вправи. Далі клієнти виконують вправи та в розробленому
застосуванні заповнювати інформацію про виконання вправ.
1.4 Рівень підготовки користувача
Користуватися цим додатком зможуть усі звичайні користувачі Android, що
мають деякий досвід роботи з цією операційною системою, або просто знайомі з
нею.
1.5 Види діяльності, функції застосування
Функції, доступні анонімним користувачам:
 авторизація;
 реєстрація.
Функції, доступні тренерам:
 перегляд та редагування профілю;
 перегляд списку клієнтів;
 перегляд профілю клієнта;
 перегляд списку програм тренувань для обраного клієнта;
 додавання та редагування тренування;
 перегляд списку вправ для обраного тренування;
 55

 додавання та редагування вправи;

 перегляд виконаних підходів клієнта;
 перегляд списку запитів від клієнтів.
Функції, доступні клієнтам тренерів:
 перегляд та редагування профілю;
 перегляд профілю тренера;
 перегляд списку тренувань;
 перегляд вправ для обраного тренування;
 перегляд списку виконаних підходів;
 додавання та редагування виконаного підходу;
 пошук тренера та створення запиту;
 перегляд списку створених запитів.
1.6 Програмні та апаратні вимоги до застосування
Для роботи мобільного застосунку необхідна версія Android 5.0, та 25 МБ
вільної пам’яті.
Для запуску сервера рекомендовано мати як мінімум процесор 2 ядра, 4 ГБ
ОЗУ та 2 ГБ вільної пам’яті. Необхідно для запуску та роботи: JDK 11+, СУБД
MySQL.
 56

2. ПІДГОТОВКА ДО РОБОТИ
2.1 Встановлення програмного забезпечення
Для встановлення мобільного застосунку достатньо просто завантажити
файл .apk та встановити як і будь-яке інше застосування Android.
Для встановлення серверної частини необхідно:
 встановити СУБД MySQL;
 створити базу даних, виконавши скрипт;
 відкрити файл ProjectRoot/src/main/resources/application.properties та
вказати відповідні credentials для БД;
2.2 Запуск web-застосування
Для запуску серверної частини необхідно перейти в кореневу папку та
виконати команду ./gradlew bootRun. Для запуску мобільного застосування
необхідно просто тапнути на відповідну іконку в меню мобільного пристрою.
2.3 Перевірка працездатності застосування
Для перевірки працездатності застосування можна виконати декілька
простих дій: наприклад, пройти авторизацію або реєстрацію.
 57

3. ПРАВИЛА ПО ЕКСПЛУАТАЦІЇ ПРОГРАМНОГО ЗАСОБУ

3.1 Операції для незареєстрованих та/або неавторизованих користувачів
3.1.1 Авторизація
Це перший екран, що побачить неавторизований користувач. На рисунку 3.1
зображено даний екран з відповідними полями та опцією вибору ролі
користувача.

Рисунок 3.1 – Екран авторизації

3.1.2 Реєстрація
Для того, щоб зареєструватися необхідно також заповнити всі необхідні
поля, обрати роль користувача та натиснути відповідну кнопку. Екран реєстрації
зображено на рисунку 3.2.
 58

Рисунок 3.2 – Сторінка інформації обраної техніки

3.2 Операції для клієнтів та тренерів

3.2.1 Перегляд списку тренувань та його редагування
Користувачі можуть переглядати список тренувань. Для тренерів доступні
кнопки видалення та редагування тренування (з правого боку елемента списку) та
додавання тренування (у нижньому правому кутку). Після натискання на елемент
списку користувач зможе перейти до списку вправ. Клієнт може тільки
переходити до списку вправ. Екран зображено на рисунку 3.3.
 59

Рисунок 3.3 – Список тренувань

Екран додавання та редагування тренування, на який можна перейти після

натиску відповідних кнопок, про які було сказано раніше зображено на рисунку
3.4.
 60

Рисунок 3.4 – Екран додавання та редагування тренування

3.2.2 Перегляд списку вправ та його редагування

Функціонал екрану перегляду вправ повністю схожий та аналогічний
функціоналу екрану перегляду списку тренувань. Так само й з екраном додавання
та редагування вправи. Екран зі списком вправ зображено на рисунку 3.5. Екран
редагування та додавання вправи зображено на рисунку 3.6.
 61

Рисунок 3.5 – Екран зі списком тренувань

 62

Рисунок 3.6 – Екран додавання та редагування вправи

3.2.3 Перегляд та редагування списку виконаних підходів вправи

Функціонал екрану перегляду виконаних підходів повністю схожий та
аналогічний функціоналу екрану перегляду списку тренувань та вправ. Так само й
з екраном додавання та редагування виконаного підходу. Але додавати та
редагувати виконані підходи може лише клієнт тренера. Тренер може лише
переглядати виконані підходи клієнтів. Екран зі списком виконаних підходів
зображено на рисунку 3.7. Екран редагування та додавання виконаного підходу
зображено на рисунку 3.8.
 63

Рисунок 3.7 – Екран зі списком виконаних підходів

 64

Рисунок 3.8 – Екран додавання та редагування виконаного підходу

3.2.4 Пошук тренера та створення запиту

Нижче наведено екран, який доступний потенціальним клієнтам тренерів.
На рисунку 3.9 зображено процес пошуку тренера, а на рисунку 3.10 зображено
діалог підтвердження відправки запиту до тренера.
 65

Рисунок 3.9 – Екран пошуку тренера

Рисунок 3.10 – Екран підтвердження відправки запиту

 66

3.2.5 Перегляд списку зроблених запитів для ролі клієнта

Клієнти можуть переглядати список зроблених запитів. На елементах
списку відображено ім’я, фамілію, логін тренера та статус запиту (не переглянуто,
прийнято, відхилено). Даний екран зображено на рисунку 3.11.

Рисунок 3.11 – Екран зі списком зроблених запитів.

3.2.6 Перегляд списку запитів від клієнтів для ролі тренера

Тренери можуть переглядати запити від клієнтів. Тренер може прийняти або
відхилити запит завдяки відповідним кнопка (галочка та хрестик відповідно). На
елементах списку також зображено фамілію, ім’я та логін клієнта. Даний екран
зображено на рисунку 3.12.
 67

Рисунок 3.12 – Екран зі списком запитів від клієнта для ролі тренера
 68

4. АВАРІЙНІ СИТУАЦІЇ
У разі виникнення аварійних ситуацій або помилок на екрані буде
відображено повідомлення що було зроблено не так і рекомендації щодо усунення
помилки. У разі аварійного припинення роботи додатку або виявлення помилки
слід повідомити розробника за яких обставин і коли це сталося, для усунення
проблеми у подальших версіях.
 69

5. РЕКОМЕНДАЦІЇ З ОСВОЄННЯ
Перш за все необхідно запевнитись у наявності підключення мобільного
пристрою до мережі інтернет та ознайомитись з даним посібником користувача.