Міністерство освіти і науки України

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

Факультет ____________________Комп’ютерних наук____________________

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

КУРСОВИЙ ПРОЕКТ
ПОЯСНЮВАЛЬНА ЗАПИСКА

тема:_________________Планувальник програм тренувань________________

(тема роботи)
з дисципліни ______Технології комп’ютерного проектування______________
(назва дисципліни)

Керівник __________________Морозова Анна Іванівна___________________

(підпис, дата, посада, прізвище, ініціали)

Студент______КНТ-19-5_________Сусла Вячеслав Олександрович_________

(група, підпис, дата, прізвище, ініціали)

Робота захищена з оцінкою «________»

«____»___________________2021_р.

Комісія:

______проф. Міщеряков Ю.В.________

(підпис, посада, прізвище, ініціали)

______ст.викл. Морозова А.І._________

(підпис, посада, прізвище, ініціали)

______проф. Овезгельдиєв А.О.______

(підпис, посада, прізвище, ініціали)

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

Факультет комп'ютерних наук

Кафедра системотехніки
Спеціальність підготовки 122 – Комп'ютерні науки
Курс _2_ група КНТ-19-5 семестр 4

ЗАВДАННЯ
на курсове проектування
студенту _______________Сусла Вячеславу Олександровичу_________________________
(прізвище, ім'я, по батькові)

1. Тема роботи: Планувальник програм тренувань

2. Термін здачі студентом закінченої роботи 06.06.21
3. Вихідні дані до проекту: Розробити серверну і клієнтську частини програмного
забезпечення «Планувальник програм трнувань». Серверна частина являє собою
реалізацію бази даних, розроблену для платформи СУБД MySQL та REST API.
Клієнтська частина має забезпечувати виконання таких бізнес-функцій. Бізнес-функції
системи для неавторизованих користувачів: реєстрація, авторизація. Бізнес-функції
системи для авторизованих користувачів, а саме тренерів та їх клієнтів. Тренер може
назначати та переглядати графік тренувань своїх клієнтів, додавати вправи до тренування
та переглядати як його клієнт з ними впорався. Клієнт має можливість переглядати графік
тренувань та вправи, а також відмічати статус виконання вправ. Операційна система –
Android 5.0 або вище, програмне забезпечення: програмний пакет MySQL Workbench,
IntelliJ IDEA, Android Studio, CASE-засоби All Fusion Data Modeler (ERWin та BPWin) та
Visual Paradigm.

4. Зміст пояснювальної записки (перелік питань, які підлягають розробці): провести

аналіз бізнес-процесів (бізнес-функцій) предметної області та виділити ті з них, які
вимагають автоматизації; сформулювати та оформити вимоги до інформаційної системи;
створити функціональну модель інформаційної системи («TO-BE»), використовуючи
стандарт IDEF0; провести функціональне моделювання, визначити й уточнити вимоги до
інформаційної системи; провести логічне моделювання БД з використанням стандарту
IDEF1Х; обґрунтувати вибір платформи СУБД для реалізації БД; провести фізичне
моделювання БД з використанням стандарту IDEF1Х; провести UML-моделювання
проектованої клієнтської частини інформаційної системи, створивши діаграму
прецедентів (Use Case Diagram), діаграму послідовності дій (Sequence Diagram),
діаграму станів (Statechart Diagram), діаграму активності (Activity Diagram) і діаграму
класів (Class Diagram); провести аналіз і виділити основні бізнес-процеси з поділом
бізнес-функцій, що виконуютьсяна стороні клієнтської і серверної частин інформаційної
системи; реалізувати фізичну модель БД для обраної платформи СУБД, створивши
серверну частину інформаційної системи; реалізувати посилальну цілісність даних, а
також одну з функцій бізнес-процесу на стороні серверної частини інформаційної
системи; реалізувати один або кілька бізнес-процесів на стороні клієнтської частини
інформаційної системи, розробивши інтерфейс доступу до БД; розробити відповідно до
ГОСТ 34.69890 експлуатаційний документ «Керівництво користувача»; підготувати
відповідно до ГОСТ 19.401-78 програмний документ «Текст програми».
5. Перелік графічного матеріалу (з точним визначенням обов’язкових креслень):
UML-діаграми, IDEF0, IDEF1X, Use Case Diagram, Sequence Diagram, Statechart Diagram,
Activity diagram
6. Дата видачі завдання: 24.03.21
Керівник роботи ____________Морозова Анна Іванівна____________________________
(Підпис) (прізвище, ім'я, по батькові)
Студент ________________Сусла Вячеслав Олександрович___________________________
(Підпис) (прізвище, ім'я, по батькові)

КАЛЕНДАРНИЙ ПЛАН
Термін
№ Назва етапів курсового проекту Примітка
виконання
1 Аналіз предметної області 30.03.2021-
07.04.2021
2 Визначення основних бізнес-функцій інформаційної 07.04.2021-
системи 15.04.2021
3 Визначення функцій інтерфейсу клієнтської частини 15.04.2021-
інформаційної системи 20.04.2021
4 Розробка серверної частини інформаційної системи 20.04.2021-
22.04.2021
5 Логічне та фізичне моделювання даних 22.04.2021-
25.04.2021
6 Створення і заповнення баз даних 25.04.2021-
30.04.2021
7 Розробка підтримки цілісності даних 30.04.2021-
15.05.2021
8 Реалізація бізнес-функцій інформаційної системи на 15.05.2021-
стороні сервера MySQL та REST API 26.05.2021
9 Розробка програмного забезпечення клієнтської 26.05.2021-
частини інформаційної системи 02.06.2021
10 Тестування розробленого програмного забезпечення 02.06.2021-
04.06.2021
11 Підготовка пояснювальної записки та її додатків 04.06.2021-
06.06.2021

Керівник роботи __________Морозова Анна Іванівна____________________________

(Підпис) (прізвище, ім'я, по батькові)

Студент_______________Сусла Вячеслав Олександрович________________________

(Підпис) (прізвище, ім'я, по батькові)
«_ » 20 р
 РЕФЕРАТ

Пояснювальна записка до курсового проекту: 56 ст., 19 рис., 3 додатки,

3 джерела інформації

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

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

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

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

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

ВСТУП ........................................................................................................... 7
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ .......................................................... 9
1.1 Аналіз предметної області ................................................................. 9
1.2 Визначення основних бізнес-процесів, які вимагають
автоматизації........................................................................................................ 9
1.3 Постановка завдання на курсове проектування............................. 10
2 РОЗРОБКА ВИМОГ ДО ІНФОРМАЦІЙННОЇ СИСТЕМИ ................ 11
2.1 Визначення функціональних вимог до системи ............................ 11
2.2 Логічне та фізичне моделювання бази даних ................................ 16
2.3 Діаграма прецедентів та діаграма послідовності (Use Case Diagram,
Sequence Diagram) ............................................................................................. 18
2.4 Діаграми класів (Class Diagrams) .................................................... 24
2.5 Діаграми активності та станів (Activity Dagram, Statechart Diagram)
............................................................................................................................. 27
2.6 Розробка вимог до функцій серверної частини системи .............. 28
2.7 Розробка вимог до функцій клієнтської частини системи ........... 29
3 ОПИС ПРИЙНЯТИХ ПРОЕКТНИХ РІШЕНЬ ..................................... 31
3.1 Обґрунтування вибору мови програмування ................................. 31
3.2 Обґрунтування вибору СУБД .......................................................... 31
3.3 Створення бази даних для платформи «MySQL».......................... 32
3.4 Розробка тригерів та збережуваних функцій БД ........................... 33
3.5 Розробка серверної частини ІС ........................................................ 34
3.6 Розробка клієнтської частини .......................................................... 35
3.7 Тестування розробленої системи .................................................... 36
ВИСНОВКИ................................................................................................. 37
ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАНЬ.............................................................. 38
Додаток А ..................................................................................................... 39
Додаток Б ..................................................................................................... 43
Додаток В ..................................................................................................... 50
 СКОРОЧЕННЯ, УМОВНІ ПОЗНАЧКИ І ТЕРМІНИ

БД – база даних
Вправа – елементарні рухи, складені з них рухові дії і їх комплекси,
систематизовані в цілях фізичного розвитку.
ІС – інформаційна система
СУБД – система управління базами даних
Тренер – особа, що має відповідну кваліфікацію та знання для
проведення тренувань, складання тренувальних програм та надання
консультацій своїм клієнтам.
Клієнт – особа, що тренується з певним тренером.
Програма тренувань являє собою вправи, розписані за днями. На певний
день вправи можуть бути підібрані або на одну чи декілька груп м’язів або
одразу на всі групи м’язів (загальні тренування). У кожної вправи задається
кількість підходів та повторень, діапазон робочої ваги. Зокрема, може
вказуватися час під навантаженням та деякі зауваження щодо виконання.
IDEF0 – методологія функціонального моделювання.
IDEF1X – методологія моделювання даних (логічної та фізичної
моделей).
Kotlin – сучасна високорівнева мультипарадигменна крос-платформена
мова програмування.
MySQL – одна з багатьох СУБД
REST API (Representational State Transfer Application Programing
Interface) – інтерфейс приклдного програмування зі стилем REST.
SQL – структурована мова запитів.
UML – уніфікована мова моделювання.
 ВСТУП

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

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

1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

1.1 Аналіз предметної області

На сьогоднішній день для того, щоб планування відбувалося ефективно
і автоматизовано, і при цьому не виникало ніяких труднощів і обмежень по
ресурсах – потрібно покращувати методи планування загального процесу і в
цілому весь підхід.
Предметною галуззю цієї курсової роботи є «Планувальник програм
тренувань». Планування тренувань – це те, що повинно відбуватися під
керівництвом тренера. Головне, щоб цей план тренувань повністю відповідав
цілям клієнта. Скинути вагу, наростити м'язову масу або просто бути в формі
– тренер повинен знати до якої мети прагне його клієнт.

1.2 Визначення основних бізнес-процесів, які вимагають автоматизації

Основними процесами даної інформаційної системи, які необхідно
автоматизувати, є складання спортивної програми тренувань та відмітка
статусу виконання вправ. Автоматизація цих процесів просто необхідна, так
як вона дає свободу в діях як і щодо тренера, так і щодо клієнта.
Автоматизуючи ці процеси, знімається велика кількість обмежень з
учасників цього великого процесу.
Тренера можуть спокійно складати тренування, використовуючи
мобільний додаток, мало того, що це буде швидко, так ще й легко, і до того ж,
тренера не зобов'язує носити з собою величезну хмару паперів, щоб
переглядати тренування своїх клієнтів, він це може зробити в будь-який
момент використовуючи смартфон.
Що стосується клієнта, він може стежити за своїми успіхами, коли
успіхи фіксуються – в першу чергу – це мотивація, мотивація робити далі і
робити більше. В якійсь мірі це контроль над собою і дисципліна, тому що
після виконаної вправи – клієнт змінює статус вправ, відповідно, це його
стимулює зробити все якісно і правильно.
 10

Основна мета проекту – це забезпечити автоматизацію процесів, які

були детально описані.

1.3 Постановка завдання на курсове проектування

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

2 РОЗРОБКА ВИМОГ ДО ІНФОРМАЦІЙННОЇ СИСТЕМИ

2.1 Визначення функціональних вимог до системи

Функіональні вимоги до системи визначають завдяки функціональному
моделюванню за методологією IDEF0. Діаграми функціональної моделі
являють собою прямокутники, що є функціями та стрілки, що їх поєднують. Є
чотири види стрілок: Вхід, вихід, керування та механізм. Далі наведено
контекстну діаграму та її декомпозиції.

Рисунок 2.1 – Контекстна діаграма

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

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

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

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

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

 13

На вхід перша функція приймає дані про користувачів, механізмами є

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

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

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

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

«Авторизуватися, аутентифікуватися» полягає в тому, щоб перевірити чи є

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

Рисунок 2.4 – Декомпозиція функції «Вести облік клієнтів та їх

тренерів»
 15

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

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

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

облік їх виконання»

Функція «Складати програми тренувань та вести облік їх виконання»

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

тренера, що є інформацією про авторизованих користувачів, робочі обов’язки

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

2.2 Логічне та фізичне моделювання бази даних

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

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

У ході визначення функціональних вимог до системи було визначено,

що клієнти можуть робити запити до тренерів, а тренери підтверджувати або
відхиляти їх. Так як декілька різних клієнтів можуть зробити запит до тренера,
і декілка тренерів можуть мати запити від одного й того ж клієнта, то виникає
зв’язок багато до багатьох. Для його вирішення було створено таблицю
request, що й відображає запит.
Наступним етапом було проектування фізичної моделі бази даних.
Фізичну модуль даних зображено на рисунку 2.7. На етапі проектування
фізичної моделі було визначено типи даних атрибутів сутностей, чи можуть
вони мати значення NULL, правила цілісноті даних та посилань.
У тренерів та клієнтів ім’я, прізвище та логін мають бути не порожніми,
а саме, логін має бути довше чотирьох символів, а прізвище та ім’я мають бути
довші двох символів. У вправах кількість підходів, повторень та вага мають
бути невід’ємними. Те ж саме стосується й виконаних підходів.
 18

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

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

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

2.3 Діаграма прецедентів та діаграма послідовності (Use Case Diagram,

Sequence Diagram)
На даному етапі було розроблено діаграму прецедентів, що відображає
можливі варіанти використання даної інформаційної системи. Акторами тут є
гості, що є неавторизованими користувачами, та тренери з клієнтами. Діаграму
прецедентів зображено на рисунку 2.8. Як можна побачити, неавторизованим
користувачам доступні лише два варіанти використання: авторизація та
реєстрація. Як і було вказано у дослідженні предметної області, тренери
можуть переглядати та створювати програми тренувань. Створення програми
тренувань включає у себе вибір дати та типу тренування, та додавання вправ
до тренування. Зокрема цього, тренер може подивитись як його клієнти
виконали назначені ним вправи. І, як було сказано раніше, тренери можуть
 19

прийняти, або відхилити запит від користувача, що авторизувався у ролі

клієнта.
Клієнт же може відправити запит тренеру, дивитись свій план тренувань
та вносити дані про виконані ним вправи.
Далі прецеденти «Назначити день та тип тренування», «Задати прави для
кожного з тренувань» та «Внести дані про виконані вправи» були
декомпозовані на діаграми послідовностей.

Рисунок 2.8 – Діаграма прецедентів

На рисунках 2.9-2.11 зображені діаграми послідовностей для

прецедентів «Назначити день та тип тренування», «Задати прави для кожного
з тренувань» та «Внести дані про виконані вправи» відповідно.
 20

Спочатку тренер вводить дані про тренування на відповідному вікні.

Далі створюється об’єкт «Тренування», що надсилається до відповідного
сервісу. Далі Сервіс проводить валідацію. Якщо валідація не пройшла, то
назад відсилається повідомлення про помилку. В іншому випадку тренування
надсилається у виді повідомлення до шару доступу до даних. Якщо
збереження пройшло успішно, то тренер бачить вікно з усіма тренуваннями, у
тому числі й щойно доданим. Якщо під час збереження трапилася помилка, то
назад відсилається повідомлення про помилку.
Послідовність дій для додавання тренування аналогічна. Спочатку
тренер вводить дані про вправу на відповідному вікні. Далі створюється об’єкт
«Вправа», що надсилається до відповідного сервісу. Далі Сервіс проводить
валідацію. Якщо валідація не пройшла, то назад відсилається повідомлення
про помилку. В іншому випадку тренування надсилається у виді повідомлення
до шару доступу до даних. Якщо збереження пройшло успішно, то тренер
бачить вікно з усіма вправами, що належать до обраного тренування, у тому
числі й щойно доданим. Якщо під час збереження трапилася помилка, то назад
відсилається повідомлення про помилку.
Аналогічна послідовність визначена й для клієнта тренера для додавання
даних про виконані вправи.
Далі наведені відповідні малюнки з діаграмами.
 21

Рисунок 2.9 – Діаграма послідовностей для прецеденту «Назначити день та тип тренування»
 22

Рисунок 2.10 – Діаграма послідовностей для прецеденту «Задати прави для кожного з тренувань»
 23

Рисунок 2.11 – Діаграма послідовностей для прецеденту «Внести дані про виконані вправи»
 24

2.4 Діаграми класів (Class Diagrams)

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

Рисунок 2.12 – Діаграма класів-сутностей

Клас User представляє собою тренерів та їх клієнтів. У даному випадку

між класом User та Workout зв’язок, як такий, не потрібен. Це обумовлюється
там, що ми будемо отримувати клієнтів та тренерів окремо від тренувань. Це
необхідно для того, щоб не завантажувати кожен раз величезний обсяг плану
тренувань, коли нам потрібен лише користувач. Тренування отримуються
окремо на відповідних сторінках інтерфейсу.
Між класом Workout та Exercise існує відношення композиції один до
багатьох. Це обумовлено тим, що у одного тренування є декілька вправ, та
вправи не можуть існувати окремо від тренувань. Аналогічна ситуація з
класами Exercise та Completed Set.
Далі наведені діаграми класів серверної частини, що реалізована у
вигляді REST API та мобільного додатку для Android.
 25

Рисунок 2.13 – Діаграма класів серверної частини

 26

Рисунок 2.14 – Діаграма класів мобільного додатку

Для серверної частини був застосований архітектурний патерн MVC з

нахилом до Clean Architecture. Можна побачити шар джерел даних DAO, за
яким йде репозиторій. Він инкапсулює у собі логіку роботи з джерелами
даних. З репозиторієм працюють інтерактори. Це об’єкти, що інкапсулюють у
собі всю основну бізнес-логіку та завдяки тому, що вони працюють з
репозиторієм, як з більш узагальненим сховищем, не потрібно буде думати та
згадувати до якого з об’єктів DAO звернутись, щоб виконати той чи інший
запит. Останнім шаром є контролери. Це об’єкти, що звертаються до
інтеракторів та обробляють повідомлення від інтеракторів. У залежності від
результату роботи інтерактору, контроллер надсилає відповідь клієнту.
 27

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

архітектурний патерн MVVM (Model-View-ViewModel). Цей підхід дещо
схожий на той, що був застосован до серверної частини. Але тут з класами, що
відповідають за відображення інтерфейсу та інтеракторами взаємодіють
сутності ViewModel, що у якості даних зберігає об’єкти LiveData. При
розробці мобільних додатків для Android цей підхід є найбільш зручним, атже
він вирішує багато проблем та складнощів.

2.5 Діаграми активності та станів (Activity Dagram, Statechart Diagram)

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

Рисунок 2.15 – Діаграма діяльності

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

В залежності того, чи відвідав клієнт тренування, він виконує вправи та

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

Рисунок 2.16 – Діаграма станів

2.6 Розробка вимог до функцій серверної частини системи

Розроблювана серверна частина системи має бути реалізована як REST
API, що є універсальним типов веб-сервісів. Завдяки універсальності, що
надають такі сервіси, з ними можуть працювати не лише мобільні пристрої,
 29

але й веб-браузерні додатки, настільні додатки та інші. Така універсальність

досягається завдяки тому, що існує єдиний стандарт роботи з веб-сервісами та
формат даних, що пересилаються.
Спілкування із даним сервісом має вібдуватися через стандартні методи
HTTP-протоколу, а саме: GET, POST, PATH, DELETE. Саме ці чотири методи
дозволяють реалізувати CRUD операції, тобто створити, прочитати, змінити
та видалити. Саме цей уніфікований стандарт дозволяє працювати REST-
сервісам із будь-якими клієнтами.
Але одного HTTP-протоколу не достатньо, щоб забезпечити роботу з
будь-якими клієнтами. Необхідно визначитися із серіалізацією даних, тобто, у
якому форматі REST-сервіс має отримувати та надсилати дані.
Сьогодні існують два найбільш популярні формати даних для передачі
їх між віддаленими сервісами, а саме: JSON та XML. Для даного сервісу був
обраний формат JSON, тому що він є найбільш популярним сьогодні та має
більш компактний та зрозумілий синтаксис, ніж XML. Більша частина REST
API сьогодні працюють саме через обраний формат даних.
Зокрема цього, такі сервіси мають бути безпечними. Не можна будь-
кому давати доступ до функціоналу веб-сервісу. Потрібно якось відрізняти
авторизованих користувачів від неавторизованих, а у нашому випадку
відрізняти ще й тренерів від клієнтів. Також, що стосується безпеки, то на
сервері має відбуватися ще й валідація даних. Таким чином, перевірка
коректності даних відбуватиметься не лише у базі даних, але й на самому
сервері. Це дозволяє дещо знизити навантаження на БД.
Мабуть, найголовнішою вимогою для клієнтів таких сервісів є
швидкісить та ефективність. Для оптимізації БД було проведено створення
ключів пошуку за деякими атрибутами на етапі проектування логічної моделі,
що дозволяє шукати дані швидше. На стороні самого REST-сервісу збільшити
ефективність можна виконуючи операції з БД паралельно та/або асинхронно.

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

Клієнтська частина системи має бути реалізована у вигляді мобільного
додатку. Головною вимогою до таких програмних засобів є швидкий та
 30

зрозумілий інтерфейс користувача. Так як ресурси мобільних пристроїв

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

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

3.1 Обґрунтування вибору мови програмування

Для реалізації серверної та клієнтської частини було обрано мову
програмування Kotlin. Це сучасна мова прогармування, що є
найпопулярнішою у розробці Android додатків, але на цій мові можна також
писати й веб-додатки. Це досягаєтся за рахунок того, що Kotlin може сумісний
із будь-якою мовою, що прцює на JVM. Так, для реалізації REST API було
використано мову Kotlin та Spring Framework.
Дана мова програмування дозволяє вирішувати більшість задач значно
легше, ніж Java, C# або інші. Це досягається завдяки легкому та приємному
синтаксису та дуже широкому функціоналу, що дозволяє полегшити життя
розробникам. Зокрема цього, Kotlin має дуже широкий функціонал, що значно
полегшує роботу з асинхронністю та паралельністю.
Завдяки різним інструментам даної мови можна пришвидшити розробку
у декілька разів. Наприклад, вказавши всього один модифікатор перед
оголошенням класу, автоматично згенеруютсья функції equals, hashCode,
конструктор з усіма вказаними властивостями та інше.
Kotlin є значно безпечнішою мовою програмування, ніж Java або інші.
Змінні поділяютсья на ті, що можуть містити null та ті, що не можуть; ті що
можуть змінюватись, та ті, що не можуть. Це зменшує кількість помилок та
верогідність критичного завершення роботи програми у декілька разів.
Все це та багато іншого, дозволяє створювати надійні програмні засоби,
що легко супроводжувати та підтримувати.

3.2 Обґрунтування вибору СУБД

Для даного проекту було обрано СУБД MySQL. Основними перевагами
даної СУБД є надійність, безкоштовність, багатофункціональність, а також
програмні засоби з графічним інтерфейсом, що полегшує роботу з даною
СУБД.
 32

Так, MySQL Workbench має зручний графічний інтерфейс, підсвітку

синтаксису та помилок, всі необхідні інструменти для супроводження та
адміністрування баз даних, інструменти для реверс-інжинирінгу.
Зокрема цього, сьогодні важко знайти хостинг-провайдера баз даних,
який не підтримував би СУБД MySQL. Цей фактор дещо полегшує розгорання
проекту, щоб ним могли користуватися всі бажаючи користувачи.

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

На даному етапі було створено базу даних за фізичною моделлю, що
була розроблена раніше. Далі був проведений реверс-інжинирінг створеної БД
засобами програмного забезпечення MySQL Workbench. Отримана схема
даних зображена на рисунку 3.1.

Рисунок 3.1 – Реверс-інжинирінг схема створеної БД

 33

Якщо порівняти отриману схему з розробленою фізичною моделлю, то

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

3.4 Розробка тригерів та збережуваних функцій БД

На даному етапі було створено тригер on_request_update, що спрацьовує
при модиіфкуванні записів у таблиці request. Його задача автоматизувати
процес підтвердження того, що користувач дійсно є клієнтом даного тренера.
Коли статус запиту змінюється на «confirmed», тригер спрацьовує та
автоматично записує відповідному клієнту у стовпчик trainer_id id
відповідного тренера. Скрипт створення даного тригера наведено на
рисунку 3.2.

Рисунок 3.2 – Скрипт створення тригеру on_request_update

Також була створена збережувана функція get_number_of_clients, яка

приймає один параметр – id тренера та визначає кількість клієнтів тренера.
Скрипт створення даної функції наведено на рисунку 3.3.

Рисунок 3.3 – Скрипт створення функції get_number_of_clients

 34

Створена база даних була перенесена на віддалений безкоштовний

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

3.5 Розробка серверної частини ІС

Для розробки серверної частини було використано мову програмування
Kotlin та Spring Framework. Обгрунтування вибору даного стеку технологій
було наведено вище.
У ході розробки було реалізовано валідацію даних, що надходять до
сервісу, обробка помилок, які виникають при введені користувацьких даних та
на сервері бази даних. Було розроблено єдиний формат відповіді веб-сервісу,
що полегшує клієнтам роботу з даним REST API. Кожна відповідь має три
поля у форматі JSON: status, message, data. Поле status містить статус
результату запиту до сервісу. Може бути або SUCCESS або ERROR. Поле
message містить повідомлення про помилку, якщо така виникає. Поле data
містить сам результат запиту (наприклад, дані, отримані з БД).
Також було проведено оптимізацію роботи з базою даних. Перш за все,
було створено пул відкритих підключень до БД, так як операція створення
підключення до БД вимагає великої кількості ресурсів. Це дозволяє повторно
використовувати підключення, а не відкривати кожен раз нові. Завдяки цьому
швидкість відповідей від REST-сервісу зросла в десятки разів. Так як база
даних розміщена на віддаленому хостингу, то щоб встановити підключення
потрібно немало часу. Під час одного запиту до веб-сервісу з урахуванням всіх
перевірок відбувалося декілька звернень до бази даних, і для кожного такого
звернення відкривалося нове підключення. Через це відповідь від
розроблюваного сервісу доводилося очікувати від 10 до 20 секунд. Після
створення пулу підключень очікування відповіді скоротилося у середньому до
інтервалу від 0,2 до 2 секунд максимум.
Ще одним оптимізаційним рішенням було зробити кожен запит до бази
даних асинхронно та паралельно на фоновому потоці. Це дуже легко
досягається завдяки корутинам Kotlin. Корутина це не поток, це просто
частина програми, що може виконуватиися асинхнонно. На одному потоці
може спокійно працювати сотні тисяч корутин і це буде працювати досить
 35

швидко, що неможливо зробити зі звичайними потоками. Kotlin дає

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

3.6 Розробка клієнтської частини

Клієнтська частина реалізована у вигляді мобільного Android додатку.
Додаток має гарний UI та UX, реалізує всі функціональні вимоги, які були
сформульовані.
Для розробки даного додатку була використана мова програмування
Kotlin та для розробки розмітки інтерфейсу мова XML. Детальний опис
графічного користувача можна знайти у додатку Б.
У ході розробки також були проведені деякі опимізації. Система Android
сама забороняє робити запити до локальних баз даних або до мережі Інтернет
на головному потоці так, як там працює графичний інтерфейс. При спробі
створити такий запит програма аварійно завершить роботу. Тому для
мережевих запитів до розробленого REST API було прийнято рішення
працювати у фонових потоках. Завдяки корутинам Kotlin всі мережеві запити
відбуватимуться паралельно та асинхронно.
Також була реалізована пагінація для тих запитів, відповіді на які
потенціально можуть мати багато даних. Прикладом є тренування. За рік у
клієнта може бути від 300 тренувань і щоб не завантажувати їх всі одразу,
завантажуватися будуть лише ті, які будуть відображатися користувачу. Це
зменшить навантаження на веб-сервіс, зробить більш раціональним
використання ресурсів мобільного пристрою, що є дуже обмеженими, та
зменшить час очікування відповіді. До цих ресурсів відноситься пам’ять,
 36

швидкодія процесору, заряд акумулятора та інші. Все це дозволяє зробити

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

3.7 Тестування розробленої системи

На даному етапі було проведено тестування клієнтської та серверної
частини. У ході тестування було перевірено всі функції. Розроблена ІС
відповідає всім висунутим вимогам та працює коректно. У разі помилки
користувачу буде надане відповідне повідомлення.
Система відмінно себе показала при різних вхідних даних, обробляла всі
некоректні дані. Інтерфейс користувача зрозумілий, швидкий та чуйний.
Запити до REST API проходять досить швидко. Тренер має можливість
назначати тренування клієнтам, клієнти у свою чергу можуть заносити дані
щодо виконання вказаних вправ. Після цього тренер може побачити дані,
внесені користувачем.
Таким чином, можна сказати, що дане програмне забезпечення повністю
готове до використання рядовими користувачами мобільних пристроїв.
 37

ВИСНОВКИ

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

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

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

1. Методичні вказівки до курсового проектування з дисципліни

«Технології комп'ютерного проектування» для студентів першого
(бакалаврського) рівня вищої освіти спеціальності 122 – «Комп'ютерні науки»
/ Упоряд.: Міщеряков Ю.В., Коваленко А.І., Решетнік В.М., Морозова А.І. –
Харків: ХНУРЕ, 2019. – 41 с.
2. Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ
систем. IDEF-технологии, 2016. – 1040 с.
3. Фаулер M. UML. Основы, 3е издание. – Пер. с англ. – СПб:
СимволПлюс, 2004. – 192 с.
 Додаток А

Текст програми
Міністерство освіти и науки України

Затверджую
Керівник
курсового проекту,
_______ст.преп. Морозова А.І.
(Підпис, дата)

ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ «МЕДИЧНИЙ ЦЕНТР»

Текст програми

Аркуш затвердження
ГЮИК. 505500.017 – 01 12 01– ЛУ

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

(Назва групи)
_______Сусла В.О.
(Підпис, дата, прізвище, ім'я, по батькові)

2021
 Міністерство освіти и науки України

Затверджено
ГЮИК. 505500.017 – 01 12 01 – ЛУ

ІНФОРМАЦІЙНА СИСТЕМА «МЕДИЧНИЙ ЦЕНТР»

Текст програми

ГЮИК. 505500.017 – 01 12 01
аркушів _2_

2021
 ГЮИК. 505500.017 – 01 12 01

CREATE TABLE `trainer` (

`id` int NOT NULL AUTO_INCREMENT,
`t_name` varchar(30) NOT NULL,
`surname` varchar(30) NOT NULL,
`login` varchar(10) NOT NULL,
`t_password` varchar(250) NOT NULL,
`phone_number` varchar(50) DEFAULT NULL,
`email` varchar(50) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `login` (`login`),
KEY `trainer_search` (`t_name`,`surname`),
CHECK (length(`t_name`) > 1 and length(`surname`) > 1 and length(`login`) > 4)
) ENGINE=InnoDB;

CREATE TABLE `client` (

`id` int NOT NULL AUTO_INCREMENT,
`c_name` varchar(30) NOT NULL,
`surname` varchar(30) NOT NULL,
`login` varchar(10) NOT NULL,
`c_password` varchar(250) NOT NULL,
`phone_number` varchar(50) DEFAULT NULL,
`email` varchar(50) NOT NULL,
`trainer_id` int DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `login` (`login`),
KEY `trainer_id` (`trainer_id`),
FOREIGN KEY (`trainer_id`) REFERENCES `trainer` (`id`) ON DELETE SET NULL,
CHECK (length(`c_name`) > 1 and length(`surname`) > 1 and length(`login`) > 4)
) ENGINE=InnoDB

CREATE TABLE `request` (

`id` int NOT NULL AUTO_INCREMENT,
`trainer_id` int NOT NULL,
`client_id` int NOT NULL,
`r_status` enum('confirmed','declined','unchecked') NOT NULL DEFAULT 'unchecked',
PRIMARY KEY (`id`),
KEY `trainer_id` (`trainer_id`),
KEY `client_id` (`client_id`),
FOREIGN KEY (`trainer_id`) REFERENCES `trainer` (`id`) ON DELETE CASCADE,
FOREIGN KEY (`client_id`) REFERENCES `client` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB

CREATE TABLE `workout` (

`id` bigint NOT NULL AUTO_INCREMENT,
`w_type` varchar(100) NOT NULL,
`w_date` date NOT NULL,
`client_id` int NOT NULL,
PRIMARY KEY (`id`),
KEY `client_id` (`client_id`),
KEY `workout_date` (`w_date`),
 ГЮИК. 505500.017 – 01 12 01

FOREIGN KEY (`client_id`) REFERENCES `client` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB

CREATE TABLE `exercise` (

`id` bigint NOT NULL AUTO_INCREMENT,
`e_name` varchar(100) NOT NULL,
`sets` tinyint NOT NULL,
`repetitions_from` smallint NOT NULL,
`repetitions_to` smallint NOT NULL,
`weight_from` smallint DEFAULT NULL,
`weight_to` smallint DEFAULT NULL,
`e_time` time DEFAULT NULL,
`notes` varchar(250) DEFAULT NULL,
`workout_id` bigint NOT NULL,
PRIMARY KEY (`id`),
KEY `workout_id` (`workout_id`),
FOREIGN KEY (`workout_id`) REFERENCES `workout` (`id`) ON DELETE CASCADE,
CHECK (`sets` > 0 and `repetitions_from` > 0 and `repetitions_to` > 0 and
`weight_from` >= 0 and `weight_to` >= 0)
) ENGINE=InnoDB

CREATE TABLE `completed_sets` (

`id` bigint NOT NULL AUTO_INCREMENT,
`set_number` tinyint NOT NULL,
`repetitions` smallint NOT NULL,
`weight` smallint DEFAULT NULL,
`c_time` time DEFAULT NULL,
`notes` varchar(100) DEFAULT NULL,
`exercise_id` bigint NOT NULL,
PRIMARY KEY (`id`),
KEY `exercise_id` (`exercise_id`),
FOREIGN KEY (`exercise_id`) REFERENCES `exercise` (`id`) ON DELETE CASCADE,
CHECK (`set_number` > 0 and `repetitions` >= 0 and `weight` >= 0)
) ENGINE=InnoDB
 Додаток Б

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

Затверджую
Керівник
курсового проекту,
_______ст.преп.Морозова А.І.
(Підпис, дата)

ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ «ПЛАНУВАЛЬНИК ТРЕНУВАНЬ»

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

Аркуш затвердження
ГЮИК. 505500.017 – ІЗ – ЛУ

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

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

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

2021
 Міністерство освіти и науки України

Затверджено
ГЮИК. 505500.017 – ІЗ – ЛУ

ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ «ПЛАНУВАЛЬНИК ТРЕНУВАНЬ»

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

ГЮИК. 505500.002 – ІЗ
аркушів _5_

2021
 ВСТУП

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

тренерами та їх клієнтами для ведення та складання плану тренувань, а також
для фіксування його виконання.
Тренер може назначити тренування на обрану дату своїм клієнтам,
внемсти дані щодо вправ, які слід виконувати, дати рекомендації щодо
виконання. Клієнт має змогу передивлятися свій план тренувань та фіксувати
виконання вправ. Тренер у свою чергу може побачити зафіксовані результати
клієнтом.
Програмним забезпеченням можуть користуватися звичайні користувачі
оперційної системи Android.
 1 ПРИЗНАЧЕННЯ ТА УМОВИ ВИКОРИСТАННЯ

Розроблене програмне забезпечення призначене для складання планів

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

Для користування необхідно упевнитись, що у користувача стоїть версія

операційної система Android 5.0 та вище, достатньо вільної пам’яті, щоб
встановити додаток. Далі необхідно завантажити додаток на мобільний
пристрій та встановити.
 3 ОПИС ФУНКЦІЙ

3.1 Опис функцій для неавторизованих користувачів

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

3.2 Опис функцій тренера

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

3.3 Опис функцій клієнта тренера

Обравши пункт меню «План тренувань», клієнт має змогу побачити
розклад своїх тренувань. Обравши тренування, клієнт побачить список вправ
до виконання. Обравши певну вправу, він зможе додати запис із
зафіксованими результатами виконання даної вправи.
 4 АВАРЙНІ СИТУАЦІЇ

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

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

Документ Vision&Scope

Vision and Scope Document

для
Проекту «Планувальник
програм тренувань»
версія 1.0

Підготовлено Сусла В.О.

Вступ 3
Мета 3
Сфера застосування 3
Визначення, абревіатури і скорочення 3
Бізнес-вимоги 3
Постановка задачі 3
Концепція (бачення) 4
Бізнес можливості 4
Бізнес ризики 5
Бізнес-контекст 5
Профілі зацікавлених сторін 5
Тренери 5
Клієнти тренерів 6
Користувачі (узагальнення) 6
Особливості продукту 6
Мобільний додаток 6
Поза зоною дії MVP 7
Інші вимоги до продукту 7
Системні вимоги 7
Допущення 7
Вступ

Мета
Мета даного документу – зібрати, проаналізувати та визначити високорівневі
потреби та особливості проекту «Планувальник програм тренувань». Він
фокусується на можливостях, необхідних для зацікавлених сторін та цільових
користувачів, і на тому, чому ці потреби існують. Деталі того, як проект
«Планувальник програм тренувань» задовольняє ці потреби детально описано
нижче у документі.

Сфера застосування
Даний документ відноситься до проекту «Планувальник програм тренувань».
Даний проект розрахований на користувачів мобільних пристроїв з
операційною системою Android. Проект надасть можливість спортивним
тренерам швидко та зручно складати індивідуальні програми тренувань
кожному своєму клієнту. У той же час їхні клієнти мають можливість
побачити свій план тренувань у зручному представлені та відмічати статус
виконання вправ. Основна мета проекту – швидке проникнення на ринок з
MVP. У подальшому проект «Планувальник програм тренувань» буде
покращено за рахунок додавання нового функціоналу та можливості
користування на пристроях iOS.

Визначення, абревіатури і скорочення

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

Бізнес-вимоги

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

Концепція (бачення)
Для тренерів та їхніх клієнтів
Хто хоче підвищити якість та ефективність складання та
виконання програм тренувань
APPS це рішення, представлене у вигляді мобільного додатку
для Android
Що забезпечує зручне складання та виконання програм
тренувань та зворотній зв’язок між тренером та їхнім
клієнтом
На відміну від існуючих способів
Даний продукт буде мати мінімально необхідний функціонал, щоб надати
зацікавленим сторонам найбільш просте та ефективне
рішення

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

На даний момент на ринку існують два найбільш конкурентоспроможні

додатки: «Freeletics» та «Карманный тренер». Ці додатки вже містять готові
програми тренувань для різних цілей. Головний недолік першого додатку у
тому, що для того щоб можна було отримати програму тренувань, необхідно
заплатити за ліцензію. Безкоштовна версія може лише слугувати як додаток, у
якому просто зібрані різні вправи та рекомендації по їх виконанню. Зокрема
цього додаток має дещо громіздкий інтерфейс користувача. Другий додаток є
безкоштовним та надає користувачу змогу обрати для себе програму
тренувань або скласти її самому. Також додаток «Карманный тренер» має
більш простий інтерфейс. Однак, ці додатки мають ряд недоліків. Зокрема,
вбудовані програми тренувань не враховують індивідуальних особливостей
людини, а якщо ж людина вирішить скласти собі програму тренувань сама, то
це може бути неефективно, або навіть зашкодити їй, якщо людина не
досвідчена в цих питаннях. Отже, ці додатки не здатні вирішити нашу
першочергову проблему.
Додаток має уникати усіх вищеназваних проблем та надати користувачам
рішення цієї проблеми. Рішення полягає в тому, щоб програми тренувань
складав тренер для своїх клієнтів. Таким чином, будуть враховані всі
індивідуальні особливості та цілі клієнтів. У кожного клієнта у додатку
відображається складена для нього програма тренувань. Під час тренувань
клієнт має змогу відмітити статус виконання вправ (скільки підходів та
повторень зробив, чи було важко або легко). Ці дані відображаються у тренера
та відштовхуючись від них він більш гнучко складає наступні тренування.
Для MVP основний робочий процес складається з наступних кроків:

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

Бізнес ризики
1. Перші версії мобільного додатку будуть функціонувати лише під
операційною системою Android. Не дивлячись на те, що це
найпопулярніша операційна система для мобільних пристроїв, все одно
приблизно 30% не зможуть користуватися даним додатком.

Бізнес-контекст

Профілі зацікавлених сторін

Тренери

Опис Особа, що використовує додаток для складання спортивних

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

Тип Звичайний користувач Android та мобільних додатків

Критерій Успіх залежить від того, наскільки тренери будуть задоволені

успіху користуванням та активно застосовувати даний додаток

Участь Не визначено
Клієнти тренерів

Опис Особа, що використовує додаток для тренувань та виконання

спортивних програм тренувань

Тип Звичайний користувач Android та мобільних додатків

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

успіху використовувати даний додаток та чи задоволені вони
функціоналом

Участь Не визначено

Користувачі (узагальнення)

Роль Опис Потреби та вимоги

Тренер Кінцевий споживач, Простий і зручний спосіб

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

Клієнт тренера Кінцевий споживач, Зручний інтерфейс перегляду

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

Особливості продукту

Мобільний додаток
APPS-1: Реєстрація
APPS-2: Вхід
APPS-3: Перегляд свого профілю
APPS-4: Перегляд списку своїх клієнтів
APPS-5: Створення програми тренувань
APPS-6: Перегляд програми тренувань
APPS-7: Можливість відмітити статус виконання вправ
APPS-8: Перегляд статусу виконання вправ своїми клієнтами

Поза зоною дії MVP

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

Інші вимоги до продукту

Системні вимоги
• Мобільний додаток має працювати під операційною системою Android
• Мобільний додаток має бути розроблено з використанням IDE Android
Studio та мови програмування Kotlin.
• Серверна частина додатку має бути розроблена з використанням Spring
Framework та мов програмування Java та/або Kotlin

Допущення

Для користування додатком як тренер, так і його клієнт мають бути

авторизовані у системі.