Мобільний застосунок «Студент ЧДТУ

Архіпов, Максим Олександрович

Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/8925

Назва:	Мобільний застосунок «Студент ЧДТУ
Автори:	Заспа, Григорій Олександрович Архіпов, Максим Олександрович
Ключові слова:	інженерія програмного забезпечення;мобільний застосунок;Flutter;ЧДТУ;проектування;цифрування;software engineering;mobile application;to design;CHDTU;Flutter;tools;digitizing
Дата публікації:	9-чер-2023
Короткий огляд (реферат):	АНОТАЦІЯ Архіпов Максим Олександрович Мобільний застосунок «Студент ЧДТУ» 121 – Інженерія програмного забезпечення Черкаси, 2023 Інженерія програмного забезпечення надає широкі можливості по цифруванню монотонної роботи з даними. Безкорисні витрати часу на черги до деканату за довідками та потреба в особистому розкладі студента, потреба в швидкому перегляді інформації про студента та проблеми при виборі дисциплін в рамках навчального семестру. Будь-яке коротке опитування або голосування вимагає від студента фізичної присутності в навчальному закладі. Все це легко виконується через мобільний застосунок. Зважаючи на складнощі студентів було прийнято рішення щодо проектування системи мобільного додатку. Було обрано стек технологій, який базується на Flutter. Розробка проводилась паралельно з навчальним процесом, тому у ході розробки були задіяні технологічні підходи до проектування системи. Як результат, була спроектована та розроблена функціональна та швидка система, яка часом на зараз вже є у вільному доступі на Google Play та в скорому часі очікується в App Store. Система є стабільною і актуальною. ABSTRACT Arkhipov Maksym Oleksandrovich Mobile application «ChSTU student» 121 – Software Engineering Cherkasy, 2023 Software engineering provides extensive opportunities for digitizing routine datarelated tasks. Useless time wasted in queues at the dean's office for certificates, the need for a personal student schedule, quick access to student information, and difficulties in choosing courses within a semester – all of these can be easily addressed through a mobile application. Any short survey or voting process no longer requires the physical presence of the student on campus. After that, we made a decision to design and develop the student personal mobile application. We put together a technologies based on Flutter. The development process was carried out in parallel with the educational process, so technological approaches to system design were used during the development. As a result, a functional and fast system was designed and developed, which is now published on Google Play and expected to be in App Store soon. The system is stable and actual.
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/8925
Розташовується у зібраннях:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Файли цього матеріалу:

Файл	Опис	Розмір	Формат
кваліфікаційна робота бакалавра Архіпов Максим Олександрович.pdf Restricted Access		12.04 MB	Adobe PDF	Переглянути/Відкрити Запит копії

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

Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем

ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень

на тему: Мобільний застосунок «Студент ЧДТУ»

Виконав: студент 3 курсу, групи ПЗС-2044
Спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)

Студент Архіпов М.О.
(прізвище та ініціали)
Керівник Заспа Г.О.
(прізвище та ініціали)
Рецензент Крайовий В.М.
(прізвище та ініціали)

Черкаси 2023

Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення

ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
Голуб С.В.
«___» ___________ 2023 року

З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Архіпов Максим Олександрович
(прізвище, ім’я, по батькові)
1.Тему проекту (роботи) Мобільний застосунок «Студент ЧДТУ»
Керівник проекту (роботи) Заспа Григорій Олександрович, к.т.н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 24 » лютого 2023
року №43/04
2. Строк подання студентом проекту (роботи) 10.06.2023
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ;
Існуючі методи та засоби розв’язання поставлених завдань;
Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем;
Розробка та тестування програмного забезпечення;
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту)
Діаграма діяльності;
Діаграма послідовності;
Діаграма прецедентів;
Діаграма класів;
Діаграма пакетів;
Діаграма комунікації;
Діаграма скінченого автомату.

6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3

7. Дата видачі завдання 23 січня 2023 р.

КАЛЕНДАРНИЙ ПЛАН
! Строк виконання

Назва етапів випускної роботи етапів випускної Примітки
п/п роботи
1 Постановка задачі 05.12.2022 виконано
2 Підготовка завдання 13.12.2022 виконано
3 Погодження завдання 16.12.2022 виконано
4 Затвердження завдання 16.01.2023 виконано
Основна стадія
1 Підбір матеріалів 06.02.2023 виконано
2 Аналіз шляхів вирішення поставленої задачі 27.02.2023 виконано
3 Розрахунок основних параметрів роботи 10.03.2023 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2023 виконано
5 Оформлення первісної редакції роботи 22.04.2023 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з керівником 10.05.2023 виконано
2 Оформлення пояснювальної записки роботи в кінцевій 19.05.2023 виконано
редакції
3 Попередній захист роботи 22.05.2023 виконано
4 Затвердження роботи 29.06.2023 виконано
5 Рецензування роботи 01.06.2023 виконано
6 Захист роботи 08.06.2023

Студент _____________________ Архіпов М.О.
(підпис) (прізвище та ініціали)

Керівник проекту (роботи) _____________________ Заспа Г.О.
(підпис) (прізвище та ініціали)

АНОТАЦІЯ
Архіпов Максим Олександрович
Мобільний застосунок «Студент ЧДТУ»
121 – Інженерія програмного забезпечення
Черкаси, 2023
Інженерія програмного забезпечення надає широкі можливості по цифруванню
монотонної роботи з даними. Безкорисні витрати часу на черги до деканату за
довідками та потреба в особистому розкладі студента, потреба в швидкому перегляді
інформації про студента та проблеми при виборі дисциплін в рамках навчального
семестру. Будь-яке коротке опитування або голосування вимагає від студента
фізичної присутності в навчальному закладі. Все це легко виконується через
мобільний застосунок.
Зважаючи на складнощі студентів було прийнято рішення щодо проектування
системи мобільного додатку. Було обрано стек технологій, який базується на Flutter.
Розробка проводилась паралельно з навчальним процесом, тому у ході розробки були
задіяні технологічні підходи до проектування системи.
Як результат, була спроектована та розроблена функціональна та швидка
система, яка часом на зараз вже є у вільному доступі на Google Play та в скорому часі
очікується в App Store. Система є стабільною і актуальною.
Ключові слова: інженерія програмного забезпечення, мобільний застосунок,
Flutter, ЧДТУ, проектування, цифрування.

ABSTRACT
Arkhipov Maksym Oleksandrovich
Mobile application «ChSTU student»
121 – Software Engineering
Cherkasy, 2023
Software engineering provides extensive opportunities for digitizing routine data-
related tasks. Useless time wasted in queues at the dean's office for certificates, the need for
a personal student schedule, quick access to student information, and difficulties in choosing
courses within a semester – all of these can be easily addressed through a mobile application.
Any short survey or voting process no longer requires the physical presence of the student
on campus.
After that, we made a decision to design and develop the student personal mobile
application. We put together a technologies based on Flutter. The development process was
carried out in parallel with the educational process, so technological approaches to system
design were used during the development.
As a result, a functional and fast system was designed and developed, which is now
published on Google Play and expected to be in App Store soon. The system is stable and
actual.
Key words: software engineering, mobile application, to design, CHDTU, Flutter,
tools, digitizing.

ЗМІСТ
ВСТУП ................................................................................................................................ 4
РОЗДІЛ 1 ............................................................................................................................ 7
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ
.............................................................................................................................................. 7
1.1. Актуальні проблеми, що виникають в процесі виконання завдань .................... 7
1.2. Методи та засоби, які вже використовуються для усунення проблем та
виконання завдань .............................................................................................................. 8
1.3. Конкретизація завдань роботи ............................................................................. 13
РОЗДІЛ 2 .......................................................................................................................... 14
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ ................. 14
2.1. Моделювання предметної області ....................................................................... 14
2.1.1. Предметна область моделювання. Модель предметної області. Словник
предметної області ............................................................................................................ 14
2.1.2. Елементи моделювання предметної області ................................................ 15
2.1.3. Робоча область моделювання ........................................................................ 16
2.2. Формування та аналіз вимог ................................................................................. 17
2.2.1. Формування вимог до програмного забезпечення ...................................... 17
2.2.2. Формування вимог за допомогою діаграми прецедентів ........................... 22
2.3. Проектування логічної структури програмного комплексу .............................. 25
2.3.1. Діаграми класів ............................................................................................... 25
2.3.2. Діаграми пакетів ............................................................................................. 29
2.4. Архітектурне проектування .................................................................................. 30
2.4.1. Діаграма компонентів .................................................................................... 30
2.4.2. Розгортання системи на апаратних засобах. Діаграма розгортання .......... 31
2.5. Моделювання поведінки системи ........................................................................ 33

ЧДТУ.232098-002 ПЗ
Зм. Лист № документа№ Підпис Дата
РЗомз.р обЛ. ист Адрохкіпуомве Мнт.аО . Дата Мобільний застосунок Літ. Лист Листів
Керівник Заспа Г.О. «Студент ЧДТУ» Д 3 95
. Н
Пояснювальна записка ФІТІС, кафедра ПЗАС,
Н.контр. Півень О.Б.
Затв. Голуб С.В. ПЗС-2044

2.5.1. Діаграма діяльності ........................................................................................ 33
2.5.2. Діаграма послідовності .................................................................................. 34
2.5.3. Діаграма комунікації ...................................................................................... 35
2.5.4. Діаграма скінченого автомату ....................................................................... 37
РОЗДІЛ 3 .......................................................................................................................... 40
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ............... 40
3.1. Розробка програмного комплексу ........................................................................ 40
3.1.1. Обґрунтування вибору засобів реалізації ..................................................... 40
3.1.2. Структурно-функціональне моделювання ................................................... 42
3.1.3. Опис логічної схеми ....................................................................................... 45
3.1.4. Розробка бази даних ....................................................................................... 47
3.1.5. Розробка інтерфейсу користувача ................................................................. 47
3.1.6. Опис розробки програмних компонентів ..................................................... 53
3.2. Тестування системи ............................................................................................... 57
3.2.1. Модульне тестування ..................................................................................... 57
3.2.2. Інтеграційне тестування ................................................................................. 58
3.2.3. Системне тестування ...................................................................................... 60
3.2.4. Приймальне тестування ................................................................................. 60
ВИСНОВКИ ..................................................................................................................... 62
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................................... 63
ДОДАТОК А .................................................................................................................... 70
ДОДАТОК Б .................................................................................................................... 74
ДОДАТОК В .................................................................................................................... 72
ДОДАТОК Г ..................................................................................................................... 90

ЧДТУ 232098.002 ПЗ
ПЕРЕЛІК УМОВНИХ ПОСИЛАНЬ

Позначення Опис
HTTP/HTTPS Hypertext Transfer Protocol / Hypertext Transfer Protocol Secure
SQL Structured Query Language
ЧДТУ Черкаський державний технологічний університет
IOS iPhone operation system
REST Representational State Transfer
API Application Programming Interface
TCP Transmission control protocol
IP Internet protocol
BLoC Business Logic Component
UML Unified modeling language
ПЗ Програмне забезпечення
JSON JavaScript object notation
UI User interface
WEB From WWW (World Wide Web)
JWT JSON web token

ЧДТУ 232098.002 ПЗ
ВСТУП
Актуальність теми. Існуюча проблема багатьох країн сьогодення – це
відставання від розвитку технологій. Сучасні гаджети зробили крок далеко вперед,
але сфери їх застосування розповсюджуються і зростають з меншими темпами.
Україна не є виключенням. Багато українських сфер діяльності ще не застосовують
сучасну техніку для полегшення умов праці та пришвидшення і збільшення
ефективності працівників. Інженерія програмного забезпечення дає можливість
спроектувати та розробити систему для вирішення проблем пов’язаних з
цифруванням сфер діяльності.
Сучасні гаджети можна примінити в найнеочікуваніших сферах діяльності.
Найлегше це зробити в сферах з молодим поколінням, яке знає ціну і переваги
сучасних апаратів. Такі включення можуть проходити дуже швидко і без супротиву
від консервативного покоління. Навчальні заклади являються гарним тому
прикладом. Сфера діяльності, де переважають студенти та учні, які по декілька сотень
раз на день взаємодіють зі смартфонами, персональними комп’ютерами та
ноутбуками, являються найкращими споживачами, що вимагають розробку та
впровадження сучасних систем автоматизації та інструментарію в наше життя.
Сьогоденні засоби вирішення деяких проблем і задач в університетах України
дуже застарілі і потребують змін та удосконалень. Ці засоби відстають від розвитку
сучасної техніки і затримують розвиток суспільства в цілому. Прикладами цього є
відсутність гарно розвинутих інформаційних системи навчальних закладів.
Включення таких систем в інші сфери діяльності вже довели ефективність таких
рішень. Більше того, сучасні світові катаклізми не дають можливості обійтись без
таких систем.
Сучасні мобільні застосунки являються тим самим необхідним прогресивним
рішенням у навчальних закладах України. Такі додатки можуть вирішувати
одночасно декілька суттєвих проблем. Серед таких наступні: зосередження та
зручний доступ до матеріалів навчального характеру, прискорення оповіщення
студентів та учнів про наближення важливих в рамках навчального процесу подій,
збільшення зручності та ефективності повсякденної взаємодії студента з навчальним
4
ЧДТУ 232098.002 ПЗ
процесом, актуалізація та швидкість отримання інформації щодо навчального
прогресу студента та інші інструменти для взаємодії студента з навчальним закладом.
Таким чином доведено, що актуальність і цінність систем, як розроблюваний
мобільний застосунок «Студент ЧДТУ», є високими на сьогодні. Проектована
система позитивно вплине на всю сферу діяльності університету і викличе позитивну
необхідність у розвитку системи в майбутньому.
Метою і завданням роботи є проектування системи для удосконалення і
оптимізації навчального процесу з боку студента у вищому навчальному закладі.
Система повинна збільшити якість досвіду навчання у закладі, збільшити
ефективність взаємодії студента з системою навчання України та зменшити витрат на
ведення облікового запису студента і зменшення неефективних звернень студента в
університетську канцелярію. Необхідно проаналізувати існуючі моделі предметної
області. Провести моделювання процесів предметної області. Спроектувати
розроблювану систему з урахуванням швидких темпів розвитку гаджетів. І розробити
гнучку до оновлень та стійку до стресових навантажень систему мобільного
застосунку.
Об’єкт розробки: моделі програмного забезпечення в сфері навчання студентів
у вищих навчальних закладах.
Методи розробки. При розробці будуть застосовані методи збору фактичних
даних, індукції, класифікації, контент аналізу. Усі ці методи необхідні для досягнення
поставленої мети у найкоротші терміни з найефективнішим результатом.
Практичне значення отриманих результатів включає впровадження нових
технологій в інформаційну систему, які забезпечують швидку і зручну роботу з
даними. Розробка нових інтерфейсів та інструментів для роботи з інформаційною
системою, що дозволяє забезпечити більш ефективне та зручне використання даних.
Результати проектування надають можливість швидко і ефективно розробити
систему мобільного застосунку для навчального закладу або оптимізувати роботу
існуючої системи. На основі зібраних даних, серед яких обмеження системи, умови
роботи та опис існуючих функцій можна легко будувати новий функціонал для
додатку – результату цієї роботи. Розроблювана система має середнє охоплення
5
ЧДТУ 232098.002 ПЗ
сфери навчання, адже є локальною системою певного навчального закладу.
Спроектовано і розроблено систему мобільного додатку для рішення поставленої
задачі по полегшенню і оцифруванню життя студентів в рамках начального вищого
закладу.

6
ЧДТУ 232098.002 ПЗ
РОЗДІЛ 1
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1. Актуальні проблеми, що виникають в процесі виконання завдань
Під час розробки мобільного додатку можуть виникати різноманітні проблеми,
які необхідно вирішувати в процесі виконання завдань кваліфікаційної роботи.
Однією з найбільш складних задач у розробці мобільного додатку є визначення
потреб користувачів та їх вимог. Для цього можуть використовуватися різноманітні
методи, такі як опитування, інтерв'ю та спостереження, однак, навіть при їх
використанні, може виникнути недостатня чіткість щодо потреб користувачів та
вимог до застосунку. З іншого боку може бути проблема недостатньої чіткості та
повноти вимог замовника. Ця проблема може виникнути через те, що замовник не має
достатнього рівня знань з технічного боку розробки програмного забезпечення. Це
може призвести до непорозумінь та неправильного розуміння вимог, що
відображається на якості розробки.
Проблема вибору технологій. В розробці мобільного додатку важливо
визначитися з використанням яких технологій буде побудовано застосунок. Сюди
входять мова програмування, фреймворк та бібліотеки на базі яких буде будуватись
проект. Ця проблема являється основою для побудови додатку. Вибір неправильної
технології або бібліотеки може привести до проблем з продуктивністю та
відповідності додатку вимогам користувачів. Більше того, в мобільному світі існують
обмеження по розробці. Береться до уваги те, на якому саме пристрої буде працювати
застосунок, які операційні системи потрібно підтримувати при розробці системи.
Існує дві основні операційні системи для мобільних пристроїв: IOS та Android. Одна
з важливих різниць між IOS та Android полягає у їх екосистемах. IOS використовує
власну екосистему Apple, що означає, що всі додатки повинні бути схвалені
компанією Apple перед тим, як вони з'являться в App Store. Це забезпечує високу
якість додатків, але також затримує процес випуску додатків. Android, з іншого боку,
є відкритою платформою, що означає, що додатки можуть бути випущені в Google
Play без обов'язкової перевірки. Це дає можливість розробникам швидко випускати
додатки, але також може призвести до меншої якості додатків.
7
ЧДТУ 232098.002 ПЗ
Ще однією важливою відмінністю є спосіб оновлення програмного
забезпечення. IOS випускає оновлення ПЗ для всіх своїх пристроїв одночасно, що
забезпечує більшу стабільність системи та забезпечує її безпеку. Android, з іншого
боку, випускає оновлення поступово для різних пристроїв, що може призвести до
різних версій операційної системи та проблем з безпекою.
Крім того, IOS має більш обмежену можливість налаштування, що робить її
більш стабільною, але менш гнучкою. Android, з іншого боку, має більші можливості
настройки та налаштування, що робить його більш гнучким, але менш стабільним.
Безпека даних. Дуже важливою проблемою при розробці мобільних додатків є
забезпечення безпеки користувачів та їх даних. Незахищений додаток може стати
легкою мішенню для хакерів та інших зловмисників.
І на останок, згадаємо про стиль написання коду. Не варто забувати, що дійсно
корисний проект може бути продовжено в розробці і доповненнях. Тому у проекті
варто встановити обмеження та рекомендації по написанню коду. В іншому випадку,
проект буде занедбано за один рік розробки і продовжувати його вже буде не можливо
і не розумно. Проблемою є також те, як саме встановити ці обмеження.
1.2. Методи та засоби, які вже використовуються для усунення проблем та
виконання завдань
Почнемо з основного – вибір технологій. Обираючи технологію та фреймворк
для розробки мобільного застосунку, слід враховувати наступні фактори:
– Кросплатформність: якщо мобільний додаток має бути доступний як на
iOS, так і на Android, слід розглянути кросплатформні технології, такі як React Native
[1], Xamarin [2] або Flutter [3].
– Досвід розробки: якщо у вас є досвід розробки на певній технології, то
може бути зручніше продовжувати роботу на цій технології. Також варто зважити на
те, які технології вже використовуються у вашій команді розробників.
– Наявність ресурсів: слід зважати на те, які ресурси, такі як бюджет,
людські ресурси та обладнання, вам доступні для розробки мобільного застосунку.
– Спрямованість додатку: в залежності від спрямованості додатку, можуть
бути кращі варіанти технологій та фреймворків. Наприклад, якщо додаток повинен
8
ЧДТУ 232098.002 ПЗ
мати велику кількість анімації, може бути краще використовувати технології, які
підтримують більше анімаційних ефектів.
– Підтримка: варто розглянути, які технології та фреймворки мають більшу
підтримку від розробників та спільноти, оскільки це може спростити роботу з
додатком в майбутньому.
Провівши аналіз ринку, можна сказати, що найкращим фреймворком для
розробки є Flutter з мовою Dart [4]. Flutter - це відкрита платформа розробки
мобільних та веб-додатків, створена компанією Google. Основними перевагами
Flutter є швидкість розробки, простота створення візуально привабливих інтерфейсів
користувача та широкі можливості налаштування дизайну додатку.
Варто зазначити, що разом з фреймворком і мовою програмування Flutter надає
і місце для завантаження пакетів або плагінів для проекту. Мова йдеться про Pub.dev.
Наступною проблемою є отримання вимог до кінцевого продукту. Це можна
вирішити багатьма методами. Але найефективніший з усіх, який активно
застосовується при розробці даного проекту – це інтервʼю з кінцевим замовником.
Для інтервʼю було розроблено прототип програми, на якому були відіграні основні
проблемні питання. Прототип підчас інтервʼю обговорювався під різними ракурсами,
що допомогло синхронизувати розуміння області розробки між клієнтом та
замовником.
Ще одним методом вирішення завдань є пошук аналогів даного мобільного
застосунку у мережі.
Основним конкурентом є мобільний додаток рівненського національного
університету [5] водного господарства та природокористування.
Як стверджують розробники, на даний момент в додатку є такі можливості:
– перегляд розкладу групи та викладачів;
– детальна інформація про пару;
– пошук аудиторії, викладача, кафедри, тощо;
– перегляд розкладу оффлайн;
– нотатки та публічні записи;
– кабінет студента та викладача із журналом успішності;
9
ЧДТУ 232098.002 ПЗ
– цифровий репозиторій;
– сповіщення та нагадування про події;
– HelpDesk підтримка у додатку;
– багато іншого.
На рис. 1.1 зображено сторінку завантаження додатку, герб та абревіатура назви
університету.
Рис. 1.1 – Вікно завантаження рівненського застосунку

Додаток розміщено у Google Play. На рис. 1.2 продемонстровані деякі екрани з
цього додатку.
10
ЧДТУ 232098.002 ПЗ

Рис. 1.2 – Знімки екранів рівненського застосунку у Google Play

Хоча додаток рівненського університет є аналогічною ідеєю, як «Студент
ЧДТУ», але він має ряд недоліків, на які необхідно звернути увагу і не допустити при
розробці. Так на рис. 1.3 зображено рейтинг додатку у Google Play. На зображені
також видно коментар користувача, який свідчить про проблеми з входом у додаток.
Рис. 1.3 – Рейтинг додатку рівненського університету у Google Play. Негативний
відгук користувача додатку

В процесі розробки гостро постало питання безпеки даних. Для цього необхідно
було забезпечити надійний захист даних, що належать користувачу. Лише власних
даних, у нашому випадку – студент, може отримати доступ до свого акаунту,
побачити інформацію, що стосується лише його. При цьому варто забезпечити
11
ЧДТУ 232098.002 ПЗ
надійну передачу даних між користувачем (мобільним додатком або клієнтом) та
сервером. Використання HTTPS є порятунком. Використання HTTPS забезпечить
безпечну передачу даних між мобільним додатком та веб-сервером.
Для того, аби ідентифікувати користувача можна використати багаторівневу
аутентифікацію. Багаторівнева аутентифікація вимагає введення кількох різних
ідентифікаторів, таких як ім'я користувача та пароль, щоб отримати доступ до даних.
Це забезпечить високий рівень безпеки та захистить дані від несанкціонованого
доступу. Замість імені користувачу буде необхідно ввести електронну адресу пошти,
яку надає університет при зарахуванні користувача.
Ще однією загрозою безпеки даних можуть бути SQL-ін'єкції. SQL-ін'єкція - це
техніка, що використовується зловмисниками для введення шкідливого SQL-коду в
додаток, який може дозволити зловмисникам отримувати доступ до бази даних. SQL
ін'єкція є однією з найпоширеніших і небезпечних атак, які можуть бути використані
для отримання несанкціонованого доступу до даних в базі даних. Для уникнення SQL
ін'єкцій рекомендується використовувати параметризовані запити, що дозволяють
відокремити дані від коду запиту.
У програмуванні лінтер [6] (англ. linter) - це програмний інструмент, що
використовується для автоматичної перевірки вихідного коду на відповідність стилю
програмування та правилам кодування.
Лінтери можуть бути вбудовані в інтегровані середовища розробки (IDE), які
надають підказки та попередження про можливі проблеми з кодом. Також можуть
бути використані як окремі інструменти для перевірки коду перед збіркою або
релізом.
Лінтери зазвичай виконують перевірку наступних аспектів коду:
– правопис імен змінних та функцій;
– відступи та форматування коду;
– використання коментарів та документації;
– використання певних функцій та методів;
– перевірка безпеки програмного коду;
12
ЧДТУ 232098.002 ПЗ
Використання лінтера допомагає знизити кількість помилок та забезпечити
більш однорідний та легко зрозумілий код, що сприяє полегшенню розробки та
підтримки програмного забезпечення.
1.3. Конкретизація завдань роботи
Для досягнення мети проекту, необхідно реалізувати низку конкретних завдань.
Основні завдання, які потрібно вирішити в рамках проекту, перелічені нижче:
– розробка архітектури та інтерфейсу користувача мобільного додатку;
– розробка функціоналу для ідентифікації користувачів та авторизації;
– розробка функціоналу для відображення інформації про розклад занять
та викладачів;
– розробка функціоналу для фільтрації розкладу занять за викладачем;
– розробка функціоналу для фільтрації розкладу занять за групою студента;
– розробка функціоналу для відображення відкритих опитувань та
можливість прийняти в них участь;
– розробка функціоналу для реєстрації на вибіркові дисципліни та
подальшого перегляду обраних предметів;
– розробка функціоналу для зв'язку студентів з підтримкою додатку через
пошту або Viber;
– розробка функціоналу для відображення новин щодо важливих подій
закладу чи оголошень;
– розробка функціоналу для генерування шаблону заяви з використанням
відомої інформації про студента;
– розробка функціоналу для відображення інформації про самого студента,
його групи, курсу, тощо.
Кожне з завдань буде розроблятись окремо, згідно з принципами Agile-
розробки [7]. Результати роботи над кожним з завдань будуть інтегровані у
відповідному розділі мобільного додатку. Для забезпечення якості програмного
забезпечення, перед випуском кожної версії додатку будуть проводитись внутрішні
та зовнішні тестування, а також код-review.

13
ЧДТУ 232098.002 ПЗ
РОЗДІЛ 2
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ
2.1. Моделювання предметної області
2.1.1. Предметна область моделювання. Модель предметної області. Словник
предметної області
В цьому розділі буде детальніше описано процес розробки мобільного додатку,
який буде використовуватись студентами черкаського державного технічного
університету. У цьому розділі будуть розглянуті основні складові проекту, описані
функціональні вимоги до додатку, а також проаналізовані проблеми.
Основний актор в розроблюваній системі застосунку – студент університету.
Саме на студентів зорієнтовано всю увагу при розробці додатку. Підчас розробки
велась робота по збору даних від вищих викладачів та адміністрації університету з
представниками деяких спеціальностей.
Зважаючи на сказане вище, функціонал додатку побудовано з потреб студента
у ході навчального процесу. Студент має потребу в наступних можливостях, які
можна забезпечити програмно:
– перегляд оголошень університету;
– отримання push-повідомлень щодо важливих подій в навчальному
процесі;
– перегляд розкладу самого студента;
– перегляд розкладу з фільтром по викладачу;
– перегляд розкладу з фільтром по групі;
– перегляд інформації про самого студента;
– налаштування додатку: можливість вимкнути push-повідомлення та деякі
налаштування окремо по функціям додатку;
– можливість переглянути доступні опитування та прийняти участь у
відкритих;
– можливість переглянути свій навчальний план;
– можливість переглянути обрані вибіркові дисципліни або обрати нові.
14
ЧДТУ 232098.002 ПЗ
У даній предметній області існують терміни, які варто описати. Серед них
наступні.
Дисципліна – навчальний предмет, який має назву, семестр, викладача, тип
кінцевого тесту знань. Наприклад, математика.
Вибіркова дисципліна - навчальний предмет, що має ті ж самі властивості, що і
дисципліна, але обирається студентом на семестр.
Процес вибору вибіркових дисциплін – це процес підчас якого студенти
обирають навчальні дисципліни на декілька семестрів вперед. Він може бути
поділений на два етапи, щоб відсіяти нецікаві студентам дисципліни.
Push-повідомлення – це повідомлення текстового і графічного характеру, які
студент отримує на смартфоні у шторці повідомлень, якщо в нього вони включені для
додатку.
Навчальний план – список дисциплін студента, розбитий по семестрам. Його
особливість в тому, що він публікується перед початком навчального семестру і
включає усю детальну інформацію про дисципліну.
Фреймворк – (з англійської Framework) це набір узгоджених компонентів
програмного забезпечення, що надає платформу для розробки програмного
забезпечення. Він забезпечує розробникам готові рішення для певних задач, таких як
взаємодія з базами даних, створення графічного інтерфейсу користувача,
маршрутизація веб-запитів, обробка помилок і т.д. Фреймворки дозволяють
розробникам зосередитися на реалізації бізнес-логіки, не витрачаючи час на
написання базових компонентів програмного забезпечення.
2.1.2. Елементи моделювання предметної області
У ході моделювання предметної області були задіяні UML діаграми [8],
діаграми станів, тощо. Серед задіяних UML діаграм були розроблені наступні види
[9]:
– діаграма класів [10],
– діаграма пакетів [11],
– діаграма компонентів [12],
– діаграма розгортання [13],
15
ЧДТУ 232098.002 ПЗ
– діаграми взаємодії: діаграма послідовності [14] та комунікації [15],
– та діаграми поведінки: діаграма прецедентів, діяльності та кінцевих
автоматів.
Усі ці діаграми дають повну картину того, як повинна працювати система і як
будуть взаємодіяти компоненти в середині.
У ході розробки застосунку будуть використані деякі фреймворки, які мають
складну взаємодію класів і компонентів всередині. На це будуть окремо створені
відповідні діаграми для візуалізації.
2.1.3. Робоча область моделювання
На розгляді робоча область моделювання мобільного застосунку «Студент
ЧДТУ». Студент може мати необхідність у використанні додатку в будь-який час
доби. Розглянемо більшість сценаріїв.
Студент відкриває додаток, входить та бачить стрічку новин університету.
Стрічку можна гортати вгору та вниз для того, аби можна було розмістити одразу
багато новин на одній сторінці. Студент може зацікавитись новиною і тоді він може
відкрити детальну інформацію по новині.
При підготовці до наступного дня навчання може виникнути потреба в
уточненні розкладу занять. Користувач відкриває застосунок в себе на смартфоні.
Попередньо він вже увійшов, тому повторної авторизації непотрібно. Обирає
сторінку «Розклад» з головного меню і бачить список своїх дисциплін.
Може виникнути додаткова необхідність у фільтруванні. Студент може
відфільтрувати розклад по викладачам або по навчальних групах. Для цього потрібна
окрема сторінка, де користувач вибере налаштування, які задовільнять його потребам
і натисне кнопку пошуку. Було б зручно, аби студент міг зберегти налаштування
пошуку під довільним ім’ям у закладки.
Наступна ситуація доволі реалістична. Раз у рік студентам необхідно брати
довідку про навчання для воєнного комісаріату. При видачі довідок студентів
запитують їх курс, факультет, кафедру і іншу інформацію, яку студенти дуже часто
забувають або взагалі не запам’ятовують. Тому в додатку студент повинен мати
16
ЧДТУ 232098.002 ПЗ
можливість переглянути особисту інформацію. Це повинна бути окрема сторінка з
усією детальною інформацією про студента в межах навчального закладу.
Раз або два рази на рік студентам необхідно обирати вибіркові дисципліни [16].
Цей процес дуже клопіткий, тому що приходиться мати справу з документами, які
постійно змінюють свій зміст та форму, та з відділом деканату, що не завжди може
приділити час студенту. В результаті ці займає дуже багато часу і зусиль. Через
додаток це можна зробити надзвичайно просто. Окрема сторінка з функціоналом
вибіркових дисциплін повинна містити список дисциплін на вибір. Щоб система була
безпечнішою, треба надати студенту можливість підтвердити свій вибір. Після того,
як дисципліни будуть обрані, студенту було б зручно бачити список його обраних
дисциплін.
Під кінець навчального семестру у студентів з’являються запитання що до
кінцевого тесту по дисциплінам або подібні. В додатку повинна бути можливість
подивитись список дисциплін, на яких студент навчається.
2.2. Формування та аналіз вимог
2.2.1. Формування вимог до програмного забезпечення
2.2.1.1. Первинні і детальні вимоги
Для виявлення вимог були використанні більшість з основних методів
виявлення вимог. Варто зазначити, що замовником мобільного додатку «Студент
ЧДТУ» являється адміністрація навчального закладу ЧДТУ. При потребі уточнення
вимог, обмежень та бізнес правил треба звертатись саме до них, як до джерела.
Інтервʼю [17]. Було проведено декілька інтервʼю з кінцевим замовником
застосунку. Підготовка до інтервʼю. Підчас підготовки до інтервʼю з замовником
складався список запитань щодо додатку і задач, які він повинен виконувати. Для
деяких функцій додатку влаштовувалися окремі інтервʼю поглиблені по вертикалі,
тобто такі, які поглиблено вивчали питання щодо однієї специфічної задачі. Підчас
інтервʼю обговорювались списки питань та встановлювалась істина щодо вимог. Для
полегшення розуміння обговорюваного матеріалу, інтервʼю підкріплювались
демонстрацією прототипу функції з приблизним користувацьким інтерфейсом. Такі
інтервʼю надавали основні вимоги до проекту.
17
ЧДТУ 232098.002 ПЗ
Спостереження [18]. Невід’ємною частиною виявлення вимог є спостереження.
Це один з найлегших, найзрозуміліших та довготривалих процесів виявлення вимог.
Обʼєктом спостереження виступав процес поводження студента з додатком. Які з
функцій додатку використовуються часто, які не використовуються зовсім. В цілому,
спостереження дозволяє отримати детальну інформацію про поведінку користувачів
та їх потреби, що дозволяє покращити дизайн та функціональність мобільного
застосунку.
Опитування [19]. Деякий функціонал може бути сумнівний до впровадження в
застосунку. З іншої сторони може бракувати розуміння потреб кінцевих користувачів
щодо функціоналу додатку. Опитування допомагає вирішити ці проблеми. Для цього
здійснюється створення плану опитування з заздалегідь зазначеними питаннями і
проводиться збір відповідей на питання зі списку.
Самостійний опис вимог. В даному проекті добре застосовано і самостійний
опис вимог. Так, як розробник являється студентом, тобто одним з кінцевих
користувачів, то самостійний опис вимог має місце (таблиця 2.1).

Таблиця 2.1
Функціональні вимоги
№ Користувач Система
кроку
1 Відкриває сторінку новин Запрошує список новин і відображає з
серверу
2 Відкриває сторінку розкладу Запрошує розклад з серверу. Сортує по
даті та відображає в зручному вигляді
3 Відкриває сторінку Запрошує список викладачів та груп з
налаштування розкладу серверу та відображає у фільтрах
4 Налаштував фільтр та натиснув Запрошує розклад з серверу. Сортує по
кнопку пошуку даті та відображає в зручному вигляді
5 Відкриває сторінку профілю Відображає інформацію про студента

18
ЧДТУ 232098.002 ПЗ
Продовж. таблиці 2.1
№ Користувач Система
кроку
6 Відкриває сторінку опитувань Відображає список опитувань з серверу
7 Обирає опитування і віддає свій Відправляє обраний голос на сервер та
голос з один з варіантів відображає вікно успіху
8 Відкриває сторінку вибіркових Запрошує список вибіркових дисциплін та
дисциплін стан з серверу. Відносно станку
відображає інформацію
9 Обирає дисципліни і Надсилає дисципліни на сервер та показує
підтверджує вибір користувачу екран успішного вибору
10 Відкриває сторінку навчального Запрошує навчальний план з серверу та
плану відображає на екрані

Для тестування вимог використовується метод еволюційного прототипування
[20]. Сенс методу полягає у створенні прототипу на кожну з функціональних вимог.
Після створення, прототип демонструють замовнику або відповідальній за це людині
та отримують відгук на покращення. Якщо вимоги були поставлені максимально
правильно і завершено, то виправлень в прототипі буде не багато. В кінці на базі
прототипу з покращеннями будується наступний функціонал, а прототип вважається
частиною цілого продукту.
2.2.1.2. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
В процесі опитувань та збору вимог до системи вдалося зібрати наступні
вимоги:
– студент може увійти в застосунок лише під своїм логіном та паролем;
– студент може вийти з застосунку закривши його, при цьому залишитись
у системі або вийти з системи взагалі;
– студент може отримувати push-повідомлення [10], які надсилає
відповідальна за це людина;
19
ЧДТУ 232098.002 ПЗ
– студент може переглянути розклад;
– студент може переглянути розклад викладача (по фільтру «викладач»);
– студент може переглянути розклад групи (по фільтру «група»);
– студент може переглянути власну інформацію у рамках навчального
закладу;
– студент може переглянути опитування і прийняти участь в будь-якому з
них за умов, що він ще цього не зробив і опитування ще відкрите і доступне; в
опитуваннях студент повинен мати змогу обрати одну або декілька відповідей;
– студент може переглянути обрані вибіркові дисципліни за умови, якщо
вибірковий процес вже завершено; якщо вибірковий процес ще тримає, студент
повинен мати змогу обрати дисципліни, які він бажає зі списку доступних йому;
– студент повинен мати можливість відсортувати та відфільтрувати
вибіркові дисципліни при виборі;
– студент може переглянути дисципліни з його навчального плану за цей та
попередні семестри;
– студент повинен мати зручну навігацію по додатку.
Після аналізу вимог замовника було сформовано список вимог розробника до
системи. Серед яких наступні вимоги:
– на формі входу необхідно додати валідацію [21] і стан помилки. Помилка
в наступних випадках: юзер ввів менше ніж три символи паролю або логіну, пароль
або логін невірні і сервер повернув помилку;
– необхідно зберегти сесію користувача [22] після логіну;
– необхідно додати чекбокс [23] «Запам’ятати мене» на сторінку логіну;
– необхідно додати перехоплювач помилки про застарілий токен від
сервера: в обробнику користувача необхідно перемістити до логін сторінки і надати
можливість поновити сесію;
– необхідно обрати сервіс для push-повідомлень;
– необхідно створити акаунт для університету на обраному сервісі та
підключити до акаунту бібліотеку з застосунку;
20
ЧДТУ 232098.002 ПЗ
– необхідно додати сторінку розкладу, розробити віджет дисципліни та
створити список дисциплін;
– необхідно додати сторінку для фільтрів розкладу;
– необхідно створити віджет з автодоповненням; для фільтру груп
підтягнути усі можливі групи, а для фільтру викладачів – усіх викладачів;
– додати функціонал закладок, щоб користувач міг зберегти під довільним
ім’ям попередній фільтр;
– необхідно розробити сторінку, де уміститься вся інформація про
студента; також треба підтягнути з сервера дані про студента на самому початку
роботи додатку;
– необхідно передбачити випадок, коли користувач має декілька
спеціальностей та випадок, коли користувач почав навчання по скороченій програмі:
повинен відображатися поточний та формальний рік;
– необхідно додати сторінку зі списком можливих опитувань: на сторінці
повинно бути видно список опитувань, включаючи їх стан (заблоковані, доступні),
дату їх створення, опис;
– необхідно додати сторінку з варіантами опитування: користувач має
змогу обрати одне або декілька варіантів одночасно; обрані пункти повинні
виділятися миттєво після їх обрання (кліку по ним); додати кнопку підтвердження
вибору і стан, коли вибір зроблено; після завершення користувача необхідно
повернути до списку усіх опитувань;
– необхідно розробити віджет вибіркової дисципліни: віджет повинен
містити в собі усю інформацію, яку надає сервер про дисципліну, мати стан
«виділено/не виділено», мати стан «дискваліфіковано» та мати розширений і стислий
режими (у розширеному, користувач бачитиме детальну інформацію про
дисципліну);
– необхідно створити сторінки для обрання дисциплін, для перегляду
обраних з подальшім підтвердженням вибору та сторінку для відображення усіх
обраних дисциплін (включаючи дискваліфіковані);
21
ЧДТУ 232098.002 ПЗ
– необхідно обробити усі можливі стани помилок і етапів обрання
дисциплін у вигляді текстових повідомлень;
– додати іконки фільтрації та сортування на сторінку; додати модальне
вікно з можливими фільтрами: зважати на наявні у списку дисципліни;
– додати віджет для дисципліни навчального плану;
– додати сторінку з дисциплінами навчального плану: сторінка повинна
містити фільтрацію по семестру і року навчання;
– розділити весь наявний функціонал на часто застосовувані та нечасто
застосовувані можливості;
– додати головне меню для часто використовуваних можливостей додатку:
меню повинно бути легкодоступне з будь-якої сторінки додатку;
– додати другорядне меню з усіма іншими можливостями; доступ до такого
меню забезпечити з основного меню.
2.2.2. Формування вимог за допомогою діаграми прецедентів
При моделюванні предметної області будуть використані UML діаграми.
Уніфікована мова діаграм допомагає створювати діаграми не залежно від проектів,
цілей та розуміти їх незалежно від рідної мови автора. UML діаграми мають список
загальних компонентів (рис. 2.1) та звʼязків (рис. 2.2).
Рис. 2.1 – Позначення UML діаграм
22
ЧДТУ 232098.002 ПЗ

Рис. 2.2 – Типи звʼязків на UML діаграмах

Зв'язки в UML-діаграмах є способом відображення взаємозв'язків між об'єктами
або класами в системі. Вони використовуються для показу, як об'єкти взаємодіють
між собою, які з них залежать один від одного та як вони взаємодіють з іншими
об'єктами в системі.
В UML існує близько 15 різних видів діаграм. Основні з них розміщені на рис.
2.3. Вони поділяються на класи.
Рис. 2.3 – Основні види діаграм та їх поділ по класах

23
ЧДТУ 232098.002 ПЗ
У мові моделювання UML існує кілька основних класів діаграм, які
використовуються для візуалізації різних аспектів системи. Основні класи діаграм
UML включають:
– діаграми структури;
– діаграми поведінки;
– діаграми варіантів використання;
– діаграми розширення.
Це основні класи діаграм UML, які використовуються для різних цілей
моделювання систем. Кожен клас діаграми має свою специфіку та використовується
для візуалізації конкретного аспекту системи.
При зборі вимог від замовника була розроблена діаграма прецедентів.
Основним і єдиним актором діаграми є студент – власник інформації додатку.
Рис. 2.4 – Діаграма прецедентів

24
ЧДТУ 232098.002 ПЗ
На рисунку 2.4 зображена взаємодія актора з додатком і показано функціонал,
який можна отримати від застосунку. Весь функціонал описано у вимогах пункту
2.2.1 вище. Основним чином користувач взаємодіє з системою за допомогою
смартфону. Інтерфейс взаємодії буде описано пізніше.
2.3. Проектування логічної структури програмного комплексу
2.3.1. Діаграми класів
За кожною функціє додатку знаходиться більше ніж один клас. На початку
розробки у стек технологій було включено становий менеджер [24] для того, аби
можна було легко контролювати стани додатку. Пізніше буде детально описано
взаємодію компонентів цієї бібліотеки.
На рис. 2.5 схема класів функції розкладу. Через особливість фреймворку
Flutter, усі сторінки додатку повинні бути віднаслідувані від базового класу. Кожна
сторінка являється віджетом. А будь-який віджет може наслідувати або Stateless, або
Stateful клас. Відповідно, віджет або буде мати стан, або ні. Від цього залежить
структура всього віджету.
Рис. 2.5 – Діаграма класів функції розкладу

25
ЧДТУ 232098.002 ПЗ
Схема класів розкладу показує наслідування від базового класу компоненту. Це
необхідно по причині використання фреймворку Flutter. Цей базовий клас надає
можливість гнучко використовувати клас у системі у різних місцях.
Базовий метод відображення повинен бути перезаписаний у насліднику. Цей
метод викликатиметься фреймворком для відображення ререндеру віджета на екрані
пристрою.
На рис. 2.6 показано ієрархію наслідування класів при побудові сторінки з
інтерфейсом.
Рис. 2.6 – Схема ієрархії класів при побудові сторінки в рамках фреймворку Flutter
починаючи з точки входу – класу «MyApp».

26
ЧДТУ 232098.002 ПЗ
Кожен елемент на екрані пристрою є віджетом. У Flutter віджет - це основний
будівельний блок для створення користувацького інтерфейсу. Він є невеликим
ізольованим елементом, який відповідає за відображення частини інтерфейсу, які
можна повторно використовувати, має свої властивості, які можна настроювати, і
може бути вкладений в інші віджети.
Stateless віджети не містять стану і можуть бути повторно використані в будь-
якому місці додатку, в той час як Stateful віджети містять стан і потребують
перерендерингу, якщо стан змінився.
Flutter містить багато вбудованих віджетів, таких як текстові поля, кнопки,
списки і так далі. Також Flutter надає можливість створювати власні віджети, які
можуть бути перевикористані в інших частинах додатку або навіть в інших додатках.
Окрім Stateless та Stateful віджетів існують інші класи, які унаслідуються від
Widget класу (рис. 2.7).
Рис. 2.7 – Схема наслідування класів-віджетів Flutter

InheritedWidget [25]: цей клас використовується для передачі даних від одного
віджету до іншого без необхідності передавати їх явно через параметри віджетів. Його
можна використовувати для створення віджетів, які мають доступ до даних, що
зберігаються вище в ієрархії віджетів.
27
ЧДТУ 232098.002 ПЗ
MaterialApp [26]: цей клас використовується для створення додатків, які
використовують Material Design [27], що є стандартом дизайну для Android. Він
містить в собі різноманітні віджети для створення елементів інтерфейсу, таких як
кнопки, текстові поля, списки та інші.
Container: цей клас використовується для створення віджетів, які можуть
містити в собі інші віджети. Він також може бути використаний для налаштування
параметрів розміщення та вирівнювання віджетів на екрані.
Ці класи є базовими компонентами для створення інтерфейсу в Flutter та
надають розробникам можливість створювати різноманітні віджети, які можна
перевикористовувати в різних місцях програми.
На рис. 2.8 схеми класів для функціоналу push-повідомлень та голосувань і
опитувань. Слід розуміти, що поза цими класами знаходяться шаблонні класи
сторінок Flutter та віджетів.
Рис. 2.8 – Діаграми класів push-повідомлень та опитувань

28
ЧДТУ 232098.002 ПЗ
Найбільший функціонал мають вибіркові дисципліни (рис. 2.9). Основна задача
сторінки – надати контрольований вибір дисциплін. Обмеженнями є кількість
дисциплін на один семестр і по одному напрямі.
Рис. 2.9 – Діаграма класів функції вибіркових дисциплін

2.3.2. Діаграми пакетів
Flutter надає можливості зручного розбиття всієї кодової бази застосунку на
пакети. Існує декілька способів поділу коду на пакети, але зупинимось на одному з
них.
Розбиття на пакети за функціональністю (рис. 2.10): розбиття програми на
пакети можна здійснювати залежно від функціональності. Наприклад, можна розбити
програму на пакети, що містять відповідальність за автентифікацію, комунікацію з
сервером, функціональні сторінки, тощо.
29
ЧДТУ 232098.002 ПЗ

Рис. 2.10 – Діаграма пакетів застосунку

Усі пакети включені у пакет модуля системи. Це стартовий модуль від якого
йде розробка. У нього включаються пакети функцій застосунку. Як розклад або
вибіркові дисципліни.
2.4. Архітектурне проектування
2.4.1. Діаграма компонентів
Компоненти у фреймворку Flutter – це віджети, які за собою мають додаткову
кодову базу для підтримки функціоналу.
Кожен пакет застосунку – це компонент, який забезпечує той чи інший
функціонал програми.
Кожен компонент знаходиться в середині рут (від англійської Root - корінь)
компонента. І всі вони поєднані компонентом меню (рис. 2.11). Так, компонент меню
створює усі інші компоненти застосунку і надає навігацію по них.

30
ЧДТУ 232098.002 ПЗ

Рис. 2.11 – Діаграма компонентів застосунку

Окремої уваги вимагає Dio компонент. Це компонент базований на бібліотеці
для мережевого зв’язку по протоколу HTTP/HTTPS. Допомагає мати зв’язок з API
серверної частини. Dio бере на себе задачі по кешуванню запитів та обробки помилок.
Бібліотека надає зручний інтерфейс для влаштування посередників для обробки усіх
вхідних або вихідних запитів.
2.4.2. Розгортання системи на апаратних засобах. Діаграма розгортання
Система застосунку складається з декількох основних частин: сервер
університету, мобільний додаток, сервер додатку, сервер розкладу та сервери баз
даних відповідно.
На рисунку 2.12 показано схему взаємодії усіх вище названих підсистем, які
забезпечують роботу основної системи застосунку. На діаграмі зображено зв’язки
між серверами і те, яка послідовність підключень цих серверів. Кожен з серверів має
свою базу даних і має зв’язок з сервером бази даних по протоколу TCP/IP. З іншого ж
боку усі сервера взаємодіють по принципам комунікації через REST API.

31
ЧДТУ 232098.002 ПЗ

Рис. 2.12 – Діаграма розгортання системи застосунку

REST API [28] - це стиль архітектури програмного забезпечення для створення
веб-сервісів, які використовують HTTP-протокол для передачі та отримання даних.
REST API використовуються для забезпечення взаємодії між різними
програмними системами, такими як веб-додатки, мобільні додатки та інші програми.
За допомогою REST API програми можуть отримувати доступ до даних та функцій
інших програм, що дозволяє їм працювати разом та взаємодіяти між собою. Але
найбільша користь у можливості написання інтерфейсу, по якому зможуть працювати
паралельно декілька розробників.
Сервер системи університету. Сервер на мові Java. Відповідає за дані студента,
списки усіх дисциплін та звітність. Має за собою базу даних з усією інформацією, що
необхідна для роботи додатку.
Сервер застосунку. Сервер на мові Java. Надає зручний інтерфейс саме для
роботи застосунку. Реалізовує аутентифікацію користувачів застосунку та деякі
специфічні задачі для додатку. За собою має базу даних з інформацією, яка
використовується застосунком. Наприклад, користувачі, їх паролі та логіни, їх
доступи.
32
ЧДТУ 232098.002 ПЗ
Сервер розкладу. Це віддалений сервер, який забезпечує надання розкладу. Не
має стандартизованого API, тому сервер додатку має обробляти відповіді від нього та
перетворювати у правильні і логічні структури, які зрозумілі на стороні додатку.
2.5. Моделювання поведінки системи
2.5.1. Діаграма діяльності
Вибіркові дисципліни є найскладнішою функцією додатку. Без діаграми
діяльності складно уявити усі доступні взаємодії та переходи. Усі описані умови на
діаграмі діяльності будуть перенесені в програму за допомогою окремих станів.
Кожен крок студента на сторінці додатку буде підписаний діаграмою.
Вибіркові дисципліни мають декілька етапів обрання. Усі етапи мають за собою
реальний час від трьох днів до декількох тижнів. Кожен стан поділяється на
додаткові. На рис. 2.13 можна прослідкувати за усіма умовами даного функціоналу.
Рис. 2.13 – Діаграма діяльності функціоналу вибіркових дисциплін

Перший період. Студент обирає дисципліни вперше. На вибір йому надано
дисципліни під його семестри та ступені. Кількість предметів до вибору задається на
33
ЧДТУ 232098.002 ПЗ
сервері в базі даних динамічно і може відрізнятися між першим і другим семестром
навчального року.
Між періодами є пауза в декілька днів, оскільки існує ручна робота у вигляді
розподілення студентів по більш популярним дисциплінам. Дисципліни, які не
набрали достатньо студентів ліквідуються або дискваліфікуються. Дискваліфіковані
дисципліни повинні бути усунені за допомогою переобрання в наступному турі.
Другий період. Студент вже обрав дисципліни в першому періоді, але має
дискваліфіковані. В такій ситуації студенту дається можливість дообрати дисципліни
з ряду тих, які є найпопулярнішими.
Після закінчення другого туру відповідальні особи переглядають рейтинги
дисциплін і можуть назначати замість дискваліфікованих інші дисципліни для
студентів, які або зовсім не обрали, або мають дискваліфіковані після першого туру і
не переобрали їх у другому. Може виникнути ситуація, коли студенту ставлять
дисципліну навіть після успішного другого туру – якщо після другого туру
дисципліну дискваліфікують. Така ситуація можлива, але дуже рідкісна.
2.5.2. Діаграма послідовності
Застосунок має обмін даними з іншими об’єктами інфраструктури системи.
Найкращий спосіб продемонструвати зв’язки у часі між системами, це діаграма
послідовності.
Весь функціонал, що перераховано у вимогах, являє собою частину на стороні
застосунку, а частину на стороні серверів. Таке розбиття задачі дозволяє виконати її
ефективніше та додає адаптивності і розширюваності даній системі. Якщо буде
прийнято зробити застосунок зі схожим функціоналом, не треба буде переносити все
з пакетів одного застосунку в пакети іншого. Адже можна буде підключити безліч
нових додатків до існуючих бекендів та без проблем працювати зі спільною
функціональністю.
Діаграма на рисунку 2.14 демонструє чіткі рамки виконання запитів від
застосунку до серверів. Самий нижній крок описує взаємодію і, фактично, принцип
роботи push-повідомлень.

34
ЧДТУ 232098.002 ПЗ

Рис. 2.14 – Діаграма послідовності системи

2.5.3. Діаграма комунікації
Мобільний застосунок має функцію аутентифікації [29]. Робота цієї функції
чудово розписана і проілюстрована на діаграмі комунікації (рис. 2.15).

35
ЧДТУ 232098.002 ПЗ
Рис. 2.15 – Діаграма комунікація компонентів системи

На рис. 2.15 комунікація відбувається між програмними системами мобільного
додатку та серверами. Два сервера взаємодіють між собою для отримання розкладу і
надалі відображення його у застосунку по фільтру або за студентом.
Для контролю станів додатку і групування та винесення бізнес логіки було
застосовано бібліотеку Bloc.
BLoC [30] - це бібліотека для Flutter, яка дозволяє легко розділити логіку
додатку від його відображення (рис. 2.16). Вона забезпечує шаблон проектування,
який називається «події-стани-перехід», і дозволяє ефективно керувати станом
додатку, реагуючи на різні події.
Основними плюсами використання BLoC в Flutter є:
Розділення логіки та відображення. BLoC дозволяє відокремити логіку додатку
від відображення, що забезпечує більшу чистоту та структурованість коду.
Стан додатку. Завдяки BLoC можливо досить зручно контролювати стан
додатку, визначати інтерфейс користувача в залежності від цього стану та реагувати
на події, що змінюють стан.
36
ЧДТУ 232098.002 ПЗ
Легко тестувати. Завдяки BLoC можливо написати відповідні тести, що
дозволить перевірити правильність роботи коду.
Масштабованість. Бібліотека BLoC дозволяє легко масштабувати додаток,
додавати нові функції та компоненти без необхідності переписувати вже написаний
код.
Загальноприйняті стандарти: Використання BLoC відповідає певним
стандартам та кращим практикам у розробці додатків з використанням Flutter, що
дозволяє забезпечити єдність коду та спростити співпрацю між розробниками.
Рис. 2.16 – Діаграма комунікації за допомогою потоків між елементами в BLoC

В цілому, використання BLoC в Flutter дозволяє забезпечити більш чистий та
структурований код, полегшує тестування та розширення додатку, а також дозволяє
забезпечити єдність та стандартизацію коду між розробниками.
2.5.4. Діаграма скінченого автомату
Вже була описана бібліотека BLoC, що дозволяє керувати станами системи. Все
це забезпечує можливість керувати такою кількістю станів (рис. 2.17), як є у
функціоналі вибіркових дисциплін.

37
ЧДТУ 232098.002 ПЗ

Рис. 2.17 – Діаграма скінченого автомату функціоналу вибіркових дисциплін. Стани
функції вибіркових дисциплін

На рис. 2.17 розміщено усі можливі стани при обранні дисциплін. Більш того,
на діаграмі розписані інші деталі для зручного керування додатком підчас розробки.
Так у додатку передбачено текстові повідомлення у деяких з випадків, коли
користувачу потрібно повідомити інформацію, щодо стану справ по вибірковим
дисциплінам.
Періоди обрання були описані вище. Але кожен період поділяється ще на
додаткові перевірки.
По-перше, студент може мати вже обрані дисципліни. В залежності від туру,
він отримає або повідомлення, або список дисциплін, які він попередньо обрав.
По-друге, студент може мати або, навпаки, не мати дискваліфіковані
дисципліни у додатку. Тут логіка більш проста. Якщо студент має дискваліфіковану
дисципліну, він повинен переобрати її в наступному турі або її призначать
автоматично пізніше після другого туру.
38
ЧДТУ 232098.002 ПЗ
Цікавим кейсом являється ситуація, коли користувач – студент першого курсу.
Першокурсники не обирають дисципліни, тому цей функціонал їм непотрібен і підчас
вибіркових турів вони бачитимуть відповідне повідомлення.

39
ЧДТУ 232098.002 ПЗ
РОЗДІЛ 3
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу
3.1.1. Обґрунтування вибору засобів реалізації
Проект реалізовано на сучасному фреймворку для мобільної розробки Flutter.
Flutter - це відкритий кроссплатформний фреймворк для розробки мобільних та веб-
додатків. Він має декілька переваг, які роблять його привабливим для розробки.
Швидкість розробки. Flutter дозволяє розробляти швидко та ефективно завдяки
гарному інструментарію для розробки і великому співтовариству розробників.
Кроссплатформність. Flutter дозволяє розробляти додатки для Android, iOS,
веб-платформ та навіть для десктопу (Windows, macOS, Linux). Це дозволяє
розробникам створювати додатки, які працюють на різних платформах з
використанням одного і того ж коду, що скорочує час розробки та знижує витрати на
розробку.
Гарна продуктивність. Flutter використовує компіляцію в нативний код та
набагато швидший віртуальний двигун, ніж у багатьох інших кроссплатформних
фреймворків. Так, цей фреймворк надає можливість писати функціонал на мовах, що
використовуються для нативної розробки. Це дозволяє додаткам Flutter працювати
швидко та плавно навіть на старих пристроях.
Гарний дизайн. Flutter надає можливість розробляти красиві та сучасні додатки
з використанням власного візуального керування (Material Design для Android і
Cupertino [31] для iOS), які виглядають однаково добре на різних платформах.
Зовнішні програмні пакети. Flutter надає доступ до багатьох сторонніх пакетів,
що розширюють можливості фреймворку. Наприклад, пакети для роботи з графікою,
відео, базами даних тощо.
Flutter вважається одним з найкращих інструментів для розробки під мобільні
пристрої на операційних системах Android та IOS.
Фреймворк має кілька конкурентів на ринку кроссплатформної розробки
мобільних додатків. Деякі з них включають:
40
ЧДТУ 232098.002 ПЗ
– React Native - фреймворк, створений Facebook для розробки мобільних
додатків для Android та iOS. React Native використовує JavaScript та має велике
співтовариство розробників.
– Xamarin – фреймворк для розробки кроссплатформних додатків для
Android, iOS та Windows, який використовує мову програмування C#.
– Ionic [32] - фреймворк, який використовується для розробки мобільних
додатків з використанням веб-технологій, таких як HTML, CSS та JavaScript.
Кожен з цих фреймворків має свої переваги та недоліки. Наприклад, React
Native має велике співтовариство розробників, але його продуктивність може бути
обмеженою, тоді як Xamarin може бути більш продуктивним, але його вартість може
бути високою.
Отже, зважаючи на вимоги до кросплатформності та великої кількості
функціоналу, який повинен швидко працювати на нативних пристроях, Flutter є
лідером з поміж конкурентів, таких як Xamarin, Ionic та React Native.
Flutter обрав Dart як мову програмування для своїх додатків.
Dart - це об'єктно-орієнтована мова програмування, яка використовується для
розробки веб-додатків, серверних застосувань, мобільних додатків та інших
програмних продуктів. Dart була створена компанією Google в 2011 році та з тих пір
стала досить популярною серед розробників. Мова програмування є досить
швидкою, що дозволяє Flutter розробляти додатки з високою продуктивністю. Dart є
повністю об'єктно-орієнтованою мовою програмування, що дозволяє розробникам
створювати класи, об'єкти та інші елементи ООП. Синтаксис Dart схожий на
синтаксис C і Java, тому для розробників, які знайомі з цими мовами програмування,
Dart може бути легким у вивченні.
Для розробки було вибрано середовище Android Studio [33]. Це інтегроване
середовище розробки (IDE) для розробки мобільних додатків для операційної
системи Android, розроблене компанією Google. Android Studio базується на IntelliJ
IDEA [34], тому воно має багато функцій та інструментів, які забезпечують високу
продуктивність та зручність в розробці мобільних додатків.
41
ЧДТУ 232098.002 ПЗ
Android Studio має потужний редактор коду, який забезпечує розробникам
можливість швидкого написання та редагування коду. Середовище використовує
компілятор Gradle, який забезпечує ефективну та швидку компіляцію коду. Та має
вбудовані емулятори, які дозволяють розробникам тестувати свої додатки без
необхідності використання фізичних пристроїв.
В цілому, Android Studio є потужним та зручним інструментом для розробки
мобільних додатків для платформи Android.
Для роботи з мережею, запитів між клієнтом і сервером використовуватиметься
пакет Dio.
Dio [35] - це пакет для мережевого програмування в Flutter, який дозволяє
виконувати HTTP-запити та отримувати відповіді з сервера. Dio має багато корисних
функцій та інструментів для роботи з мережею, таких як підтримка різних типів
запитів, автоматичне декодування JSON-відповідей, обробка помилок та багато
іншого.
Dio ідеально підходить для розробки мобільних додатків зі складними
мережевими запитами, таких як авторизація, отримання списку елементів з сервера,
відправка файлів на сервер тощо.
3.1.2. Структурно-функціональне моделювання
Для опису структурної схеми буде застосовано графічне зображення схеми. На
рис. 3.1 показано значення елементів схеми.
Рис 3.1 – Основні графічні символи для опису функціональної схеми: а) процес,
підсистема; б) ручне введення; в) пристрій пам’яті з прямим доступом; г) дисплей;
д) документ
42
ЧДТУ 232098.002 ПЗ

Рис. 3.2 – Структурна схема застосунку

На рис. 3.2 зображено структурну схему додатку. Усю систему можна розділити
на підсистеми і окремі системи, які можуть взаємодіяти самостійно. Де система
додатку є основним модулем системи. Вона відповідає за усі інші системи та
підсистеми і взаємодію між ними.
На рисунках 3.3 та 3.4 зображено функціональні схеми у загальному та
детальному масштабах відповідно. На схемах описано, як відбувається рух даних між
компонентами, показано на якому етапі вони вводяться від користувача і на якому
етапі вони транслюються на екран пристрою. На схемі не показано збереження даних
до постійних сховищ або тимчасових змінних, це не є важливим в даному контексті.

43
ЧДТУ 232098.002 ПЗ

Рис. 3.3 – Функціональна схема загального масштабу. Функціональна схема системи
повідомлень

Рис. 3.4 – Функціональна схема детального масштабу системи вибіркових дисциплін

Загальна схема працює по сценарію отримання даних з серверу та відображення
їх на екрані користувацького пристрою. У більш детальному масштабі, усі підсистеми
застосунку працюють по схожому принципу. Їх розгляд не має сенсу. Задача
підсистеми – отримання і обробка даних з серверної частини, відображення їх
користувачу та отримання від користувача наступних команд.
44
ЧДТУ 232098.002 ПЗ
3.1.3. Опис логічної схеми
Для того, аби мати змогу працювати з користувацькими даними, застосунок
повинен витягнути інформацію про користувача з серверу. Звісно, для цього
користувач повинен пройти аутентифікацію і підтвердити свою особистість.
Аутентифікація. Коли користувач вперше входить у додаток, він опиняється на
сторінці авторизації з формою логіну. Авторизація вважається вдалою, якщо
користувач ввів правильний логін та пароль. Після чого у відповідь від сервера
застосунок отримає загальну інформацію про користувача. Ця ж інформація
застосовується на сторінці профілю і при наступних запитах до серверу. Разом з тим,
додаток отримує JWT, який буде збережено на стороні застосунку і буде
використовуватись для підпису запитів до серверу.
Навігація. Навігація по додатку реалізована за допомогою двох меню і стейт-
менеджеру, який зберігає стан і керує переходом між сторінками. Основне меню (рис.
3.5) – меню знизу додатку, набір найосновніших функцій додатку. Ці функції мають
найбільший пріорітет. Коли користувач натискає на якусь сторінку з меню, становий
менеджер дає команду на зміну сторінки та записує поточну сторінку до пам’яті часу
виконання. Останній пункт означає, що після перезапуску програми стан не буде
відновлено і користувач почне з першої, стартової, сторінки.
Рис. 3.5 – Головне меню навігації

Новини, заяви та навчальний план. Логіка цих сторінок дуже проста і подібна.
Основна ціль – це відобразити контент. Для цього існує модуль з бібліотекою Dio.
Його задача здійснити запит на сервер і повернути відповідь сторінці для
відображення. HTTP модуль використовується не лише розглянутими сторінками.
Деякі зі сервісів потребують додаткового кешування відповідей від серверу. Для
45
ЧДТУ 232098.002 ПЗ
цього необхідно передати в метод запиту параметр «cacheEnabled» значення «true».
При кешуванні зберігається значення відповіді з серверу у вигляді ключ-значення.
Ключем виступає хеш запиту, а значенням – відповідно, результат запиту. Хеш запиту
створюється методом «genCacheId» (рис. 3.6). Метод приймає обʼєкт RequestOptions
– це обʼєкт параметрів запиту, який надсилається до бекенду. Для того, аби створити
кеш з параметрів, усі основні параметри запиту, які можуть мати різницю від запиту
до запиту склеюються в єдиний рядок у вигляді маршруту. Для більшої зручності і
оптимізації, отриманий рядок перетворюється на число за допомогою вбудованого в
клас String методі «hashCode». Отримане значення повертається з функції. При цьому
закешовані данні зберігаються 5 хвилин. При наступному подібному запиті протягом
5 хвилин спочатку буде перевірено існування кешу і тільки якщо кешу по даним
параметрам запиту не виявлено, буде здійснено новий запит до серверу і результат
буде збережено, як кеш.
Рис. 3.6 – Код методу для генерації кеш-коду по параметрам HTTP запиту

Запис на вибіркові, розклад та опитування. Цей функціонал вже має більше
бізнес логіки. Але загалом все працює подібним чином – отримано результат від
сервера, показано на екрані, реакція на дії користувача. Усі три підсистеми мають
додаткові сторінки. Розклад має сторінку з налаштуваннями для виборки по
параметрах, а запис на вибіркові та опитування мають по дві додаткові сторінки і
додаткові стани. Так, сторінка вибіркових дисциплін має стан вибору дисциплін. На
діаграмі скінченого автомату з другого розділу розписані усі умови і вихідні значення
даної системи. Схема опитувань набагато простіша і не містить умов. З сервера
приходить інформація по доступним для студента опитуванням, включаючи дату, час,
46
ЧДТУ 232098.002 ПЗ
стан (чи було віддано голос вже), опис та назву з варіантами відповідей. Студент
обирає одне опитування зі списку і отримує варіанти голосування. Проте деякі
опитування можуть мати багатоваріантний або одиничний тип. Після кожної
відповіді користувача відбувається перевірка того, скільки ще є доступних відповідей
у студента, якщо обрано максимальну кількість варіантів для цього опитування, то
усі інші відповіді блокуються.
Профіль. Профіль студента – це одна з найпростіших сторінок додатку. Уся ціль
сторінки заключається в тому, щоб відобразити інформацію про студента.
Інформацію про студента додаток отримує після авторизації. Таким чином для
профілю навіть не треба робити додатковий запит. Інформація про користувача
знаходиться у статичній змінній блоку (класу) App.
3.1.4. Розробка бази даних
Застосунок не містить локальної бази даних. Звісно, інформацію треба
зберігати, але цим займається серверна частина застосунку. Уся логіка по обробці,
запису, зчитування і подібних процедур з базою даних також знаходяться на сервері.
За потреби збереження даних використовуються можливості мобільних фреймворків,
такі як «Shared Preferences» в Android або «User Defaults» на IOS. Це звичайні
механізми з запису ключ-значення даних, які не потребують додаткового опису.
3.1.5. Розробка інтерфейсу користувача
Існує чудова книга, яка описує вимоги до грамотного дизайну веб-сторінки.
Автор Якоб Нільсен, «Веб-дизайн». У книзі автор описує вимоги до бажаного
користувачами дизайну веб-сайту. Дана робота не про веб-сайт, але описані у книзі
вимоги є абстрактними і ним можуть належати будь-які UI-системи. Основні умови,
описані в книзі, включають:
– Ясність та простота: веб-сайт повинен бути легким у сприйнятті та
легким у використанні, а також повинен мати чітку структуру та зрозумілий
інтерфейс.
– Контент: веб-сайт повинен мати вміст, який користувачі шукають, і
повинен бути оновлюваним на регулярній основі.
47
ЧДТУ 232098.002 ПЗ
– Навігація: веб-сайт повинен мати чітку навігацію, щоб користувачі могли
легко знайти те, що їм потрібно.
– Пошук: веб-сайт повинен мати функціонал пошуку, щоб користувачі
могли швидко знайти необхідну інформацію.
– Розуміння користувачів: веб-сайт повинен бути створений з урахуванням
потреб та очікувань користувачів.
– Доступність: веб-сайт повинен бути доступним для всіх користувачів,
включаючи тих, у кого є обмеження здатності сприймати інформацію.
– Дизайн: веб-сайт повинен мати привабливий та професійний дизайн, що
відображає бренд та стиль організації.
Перенесемо усі ці умови на дизайн розроблюваного застосунку, порівняємо і
з’ясуємо, чи втілено ту чи іншу вимогу до дизайну мобільного додатку «Студент
ЧДТУ».
Ясність та простота. Розроблюваний застосунок має простий сенс – надати
користувачам різного роду функціонал та інструментарій для взаємодії з системою
університету. Ціль є легкою і прозорою, тож і дизайн повинен відповідати цілі. Для
цього увесь функціонал розфасовано по окремим функціям. Якщо користувач
заходить з єдиною ціллю застосувати певний інструмент, він буде мати можливість
працювати лише з бажаним інструментом і не буде мати проблем з відображенням
багатьох функцій на спільній сторінці. Ясність продукується тим, що кожна сторінка
додатку має чітку ціль і підпис. З цього боку існує два типу сторінок: основні і побічні.
До основних відносяться сторінки, які знаходяться на основному екрані та містять в
собі головне меню. До побічних сторінок відносяться усі інші сторінки, які
відкриваються у додатковому вікні і мають підпис зверху. На рис. 3.7 показано обидва
типи сторінок і продемонстровано ясне розподілення функціоналу по сторінках та
підписи другорядних сторінок.
Навігація. Для швидкого пошуку потрібного інструменту передбачено два типи
навігації. Перший тип – це основне меню. Його видно на будь-якій основній сторінці,
що допомагає швидко перемикатися між важливими сторінками додатку. Другий тип
– це другорядне меню або «інше». Це список усіх додаткових інструментів, які не
48
ЧДТУ 232098.002 ПЗ
помістилися до основного меню або використовуються дуже не часто для їхнього
розміщення у основному меню.
Рис. 3.7 – Знімки екрану навчального плану та сторінки профілю

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

Рис. 3.8 – Другорядне меню застосунку «Студент ЧДТУ»

Розуміння користувачів. Для даного застосунку це не є критичним пунктом,
адже додаток розроблено на певну специфічну аудиторію. При розробці дизайну
проводились опитування до діючих студентів ЧДТУ для покращення і розробки під
студентів відповідного навчального закладу.
Доступність. Шрифт та розмір шрифту підібрано з цілями читабельності.
Додаток не містить багато кольорів для шрифту і усі кольори підібрані з
максимальною контрастністю. Додаток підтримує різну ширину екранів. Якщо
користувач відкриє програму на великому пристрої, інтерфейс розтягнеться по
ширині та висоті пристрою користувача, але залишатиметься читабельним та чітким.
50
ЧДТУ 232098.002 ПЗ
Теж саме стосується малих екранів пристроїв. В додатку не реалізовано механізмів
для сліпих, це зайняло б занадто багато часу на розробку і не було зазначено у
вимогах. Проте при застосуванні скрінрідерів (від англ. screen reader – екранний
читач) користувач з обмеженням по зору зможе впоратись з управлінням додатком.
При розробці були дотримані усі правила розробки для підтримки професійних
скрінрідерів.
Контент. Весь функціонал додатку має динамічний контент та не містить
жорстко закодованої інформації. Весь контент сторінок підтягується з баз даних за
допомогою мережевих запитів до серверу. За необхідності, вся інформація легко
редагується адміністраторами загальної системи і систем, дані яких
використовуються додатком. Наприклад, система розкладу.
Пошук. Доволі рідкісне явище централізованого пошуку у мобільних додатках,
особливо додатків з малою кількістю очевидних та постійно застосовуваних
інструментів. Але для інтерактивного і розумного пошуку знайшлося місце в
функціоналі розкладу. Розклад має декілька основних параметрів. Це час, викладач,
група дисципліни. Саме по цим параметрам є можливість здійснити пошук у додатку.
Для зручності пошуку і кращого користувацького досвіду реалізовано функціонал
збереження закладок з налаштуваннями пошуку. Якщо наступного разу знадобиться
шукати по тим же самим параметрам, достатньо буде натиснути на закладку і
здійснити пошук. На рис. 3.9 продемонстровано функціонал пошуку за групою, датою
та викладачем. Для кращого користувацького досвіду використано автокомліт для
полів введення. Достатньо почати вводити, як система надасть можливі варіанти для
обрання.
Дизайн. Весь дизайн обумовлений в першу чергу простотою реалізації.
Функціонал без дизайну може бути виправданий стислими термінами розробки.
Проте з дизайном розроблюваного додатку не все так погано. Весь стиль додатку
обіграно навколо головного логотипу університету (рис. 3.10). Кольорова гамма
підбиралась відповідно до кольорів логотипу та була затверджена менеджером
проекту.
51
ЧДТУ 232098.002 ПЗ

Рис. 3.9 – Функціонал пошуку розкладу за параметрами

Рис. 3.10 – Логотип ЧДТУ

52
ЧДТУ 232098.002 ПЗ
Також при розробці і проектуванні дизайну застосунка бралось натхнення з
попереднього дизайну. Попередній дизайн був невдалим у багатьох аспектах, але мав
і свої переваги та гарні якості. Звісно, усе, що не подобалось студентам, було усунуто
і виправлено. Багато деталей виправлялось вже після написання додатку на етапі
тестування.
3.1.6. Опис розробки програмних компонентів
Головним модулем в системі є модуль для здійснення HTTP запитів до
серверної частини. Для реалізації функціоналу була використана бібліотека Dio з
пакетного менеджера Flutter Pub.
Dio - це пакет для мови програмування Dart, який надає зручний і простий
інтерфейс для виконання HTTP-запитів до веб-сервера. Dio можна використовувати з
бібліотекою Flutter для розробки мобільних додатків. Dio забезпечує можливість
відправляти різні типи запитів, включаючи GET, POST, PUT, PATCH, DELETE,
HEAD, OPTIONS, а також підтримує роботу з файлами та заголовками запитів. Крім
того, Dio має можливості для обробки помилок, включаючи обробку статусів
відповіді HTTP та звичайних помилок мережі. Dio є одним з найбільш популярних
пакетів для виконання HTTP-запитів у Flutter-розробці. Для його використання
необхідно підключати пакет до проекту, додавши залежності, та налаштувати два
важливих класи.
GlobalInterceptor. Цей клас відповідатиме за перехоплення усіх запитів та
підпису їх JWT і додаванням необхідних заголовків до запиту. Необхідно наслідувати
від класу Interceptor. Наслідуваний абстрактний клас містить три абстрактні методи,
що є обов’язковим для імплементації у розроблюваному класі: «onRequest»,
«onResponse» та «onError».
На рис. 3.11 продемонстровано реалізацію першого методу абстрактного класу.
Основна задача методу, прийняти запит, його параметри, обробити і надіслати далі
по ланцюгу виконання.
«onResponse» та «onError» (рис. 3.12 та 3.13 відповідно) - це методи, які
викликаються модулем після повернення відповіді від сервера. Дуже зручно
перехоплювати відповідь і обробляти помилки в одному місці централізовано.
53
ЧДТУ 232098.002 ПЗ

Рис. 3.11 – Код методу «onRequest»

Рис. 3.12 – Код методу «onResponse»

У цьому ж класі реалізовано метод «addHeaders», лістинг якого надано на
рисунку 3.14. Основна ідея методу у винесенні додавання усіх необхідних заголовків
в одному місці.
Для застосування Dio підчас запитів, створюється абстрактний клас з
необхідними методами обробки та додавання інтерцептору. У класі реалізовано
54
ЧДТУ 232098.002 ПЗ
патерн Singleton, який допомагає мати єдиний Dio об’єкт на весь час виконання
програми. Тепер для використання описаної логіки необхідно отримати через геттер
класу Dio-об’єкт та виконати запит до сервера через отриманий об’єкт.
Рис. 3.13 – Код методу «onError»

Рис. 3.14 – Метод по додаванню заголовків

На рис. 3.16 продемонстровано приклад, як застосовується Dio об’єкт для
здійснення запитів до серверу. У даному випадку реалізовано метод для здійснення
авторизації.

55
ЧДТУ 232098.002 ПЗ

Рис. 3.15 – Реалізація абстрактного Dio класу-обгортки
Рис. 3.16 – Клас провайдера з застосуванням класу Dio для здійснення запитів до
серверу

56
ЧДТУ 232098.002 ПЗ
3.2. Тестування системи
3.2.1. Модульне тестування
Для проведення модульного тестування необхідно встановити спеціальну
програму з емулятором Android та IOS пристрою. Емулятор - це програмне
забезпечення, що імітує працю фізичного мобільного пристрою на комп'ютері. Це
дозволить випробовувати та тестувати застосунок на різних версіях Android і IOS та
різних типах пристроїв без потреби мати фізичний екземпляр. У свою чергу, це
значно пришвидшує розробку і тестування. Емулятор надає зручний спосіб
перевірити, як виглядає додаток на екрані, перевірити, як працює функціонал, який
залежить від певних параметрів, таких як зміна орієнтації екрану, розмір екрану,
тощо.
Модульне тестування мобільного застосунку починається з визначення
тестових сценаріїв до кожного з розроблених модулів. Сценарії складаються в кінці
розробки кожного з модулів та перевіряються по завершенню написання модуля.
На основі вимог до функціональності кожного модуля необхідно визначити
тестові сценарії, які мають бути перевірені. Наприклад, для модуля "Розклад" можна
визначити тестові сценарії, які будуть перевіряти правильність відображення
розкладу, обробку помилок, коректність розміщення інформації на екрані і так далі.
На основі визначених тестових сценаріїв можна написати тести. Це можна
зробити, використовуючи бібліотеку flutter_test [36], яка надає можливість написати
тестові сценарії на мові Dart. Після написання тестів їх необхідно запустити. Проте в
даному випадку написання тестів не є виправданим зважаючи на часові рамки.
Після того, як програмний модуль було написано і проведено тест, необхідно
аналізувати його результати. У більшості випадків після аналізу тесту виявляються
помилки або не відповідності з вимогами. Після чого відбувається виправлення або
перепис функціоналу. Якщо тести пройшли успішно, можна продовжувати роботу
над іншим модулем і його тестуванням.
Таким чином на етапі модульного тестування були перевірені усі розроблювані
компоненти. Більшість потребувала внесень змін та ретесту. Після повторного
57
ЧДТУ 232098.002 ПЗ
тестування було підтвердження готовності компоненту до впровадження в кінцевий
застосунок.
3.2.2. Інтеграційне тестування
Даний тип тестування повинен проводити незалежний тестувальник. Задача
тестування перевірити взаємодію модулів при цьому скривається внутрішня будова
модулів. Незалежний тестувальник не повинен знати про внутрішню будову модуля,
це може спричинити пропуск потенційної проблеми або помилки. Якщо модуль
працюватиме правильно, то гарантувати, що в ньому немає помилок неможна. Можна
лише стверджувати, що помилки не були знайдені після тестів певного рівня
деталізації.
В вимогах не зазначалась необхідність розробки автоматичних тестів, тож усі
тести проводитимуться мануально, незалежним тестувальником, який не знає
внутрішньої будови додатку. Щоб збільшити покриття тестових сценаріїв тестами,
було створено тестову групу для Beta тесту у Google Play (рис. 3.17).
Рис. 3.17 – Приклад beta тесту в Google Play

Для того, аби мати можливість отримувати зворотній зв’язок від користувачів,
у додатку передбачено зручний метод надіслання поштою відгуків про помилки.
Середня кнопка на рис. 3.18.
58
ЧДТУ 232098.002 ПЗ

Рис. 3.18 – Додаткові кнопки керування: налаштування додатку, технічна підтримка
та вихід з додатку відповідно

У додатку інтегровано сторонній сервіс push-повідомлень Onesignal [37].
Одним зі сценаріїв тестування є перевірка взаємодії зі стороннім сервісом. Цей сервіс
використовується для розсилки push-повідомлень на пристрої через додаток, надає
функціонал глибокого лінкінгу (від англ. deep link) та сервер для розсилки
повідомлень. Сервіс надає зручний інструментарій для тестування. Для
інтеграційного тесту достатньо створити тестове повідомлення і натиснути кнопку
«Надіслати на тестовий девайс», що продемонстрована на рис. 3.19.
Рис. 3.19 – Тестування push-повідомлень сервісу Onesignal

Тест Onesignal вважається вдалим після отримання push-повідомлення на
тестовому пристрої.
59
ЧДТУ 232098.002 ПЗ
3.2.3. Системне тестування
Після завершення інтеграційного тестування необхідно перевірити систему в
цілому. Продовження beta тесту є гарною ідеєю, оскільки це зменшує ризики
пропустити помилку. Основна мета системного тестування це перевірити, чи
відповідає додаток вимогам та чи задовольняє він потреби користувачів.
Для того, аби переконатись, що усі вимоги виконано, було проведено декілька
демо з використанням екземпляру додатку на реальних пристроях. Після демо подій
проводився аналіз відгуків від учасників події.
У більшості випадків, змін після демо не вноситься. Але є і виключення. Проте
після внесення змін ще одне демо не проводилось. І умови вважаються дотриманими,
адже головний функціонал працює справно.
3.2.4. Приймальне тестування
Етап впровадження системи являється одним з заключних етапів розробки.
Впровадження мобільного застосунку полягає в розміщенні програми на
маркетплейсі (Google Play та App Store) і відкриття доступу для всіх бажаючих. Після
відкриття доступу і надання можливості реальним користувачам завантажувати
додаток, проводиться курс по ознайомленню з додатком та його функціоналом.
Більшість розробленого функціоналу не є чимось особливим або складним для
використання, тому не потребує пояснення. Користуватись легко – досить лише
відкрити необхідну сторінку з головного меню.
Користувацька інструкція по використанню додатку «Студент ЧДТУ»
елементарна. Для того, аби почати користуватись додатком, у разі, якщо людина
діючий студент університету, необхідно запросити пароль для входу у додаток в
деканаті університету. Логіном для входу слугує внутрішня пошта студента. Після
отримання паролю необхідно завантажити додаток з магазину застосунків
операційної системи. Після того, як застосунок був завантажений та відкритий,
користувач побачить сторінку логіну (рис. 3.20). Від користувача вимагається
введення логіну та паролю для продовження роботи з додатком.
60
ЧДТУ 232098.002 ПЗ

Рис. 3.20 – Сторінка логіну у застосунок «Студент ЧДТУ»

Після того, як користувач увійшов, додаток вважається налаштованим і є
придатним для використання. Детальнішу інструкцію користувача можна знайти у
додатках (Додаток В).
Будь-яку систему можна вдосконалювати вічно. Проте є пріоритетні місця, які
вартують вдосконалення у найближчому майбутньому. Одним з таких місць є модуль
розкладу. Проблема розкладу в тому, що використовується сторонній сервіс для
отримання розкладу занять. Небезпека у надійності сервісу. Якщо не працюватиме
сервіс – не працюватиме і функціонал розкладу у додатку. Другим мінусом є
неточності в розкладі. Система розумного фільтру на сервері потребує додаткового
чекбоксу для ввімкнення фільтру. Це поскладнює логіку додатку та збільшує час
обробки інформації.
Висновки до розділу. Система легка та інтуїтивна у використанні і не потребує
додаткових курсів по ознайомленню з функціоналом, який існує часом на зараз.
Кожен модуль має власні підказки та пояснення, користувачу достатньо лише
задуматись про необхідність використання того чи іншого інструменту.
61
ЧДТУ 232098.002 ПЗ
ВИСНОВКИ
На початку роботи були поставлені приблизні вимоги до кінцевого продукту. В
ході роботи були уточненні і зібрані повні вимоги до розроблюваної системи та
проведено роботу по проектуванню системи застосунку. Зважаючи на усі поставлені
задачі, було спроектовано та описано ряд UML діаграм за якими в подальшому
створювалась система. По завершенню розробки кожного з модулів і системи загалом
було проведено ручне тестування, яке підтверджує відповідність системи
поставленим вимогам. В застосунку реалізовані усі поставлені задачі і часом на
сьогодні він опублікований у Google Play Market [38] та доступний всім студентам
черкаського державного технічного університету.
Система має усі затребувані функції і стабільно виконує задачі, які ставлять
перед нею студенти університету. Проте, варто порівняти його з існуючими
аналогами, які були знайдені та досліджені перед початком роботи.
Основним конкуруючим аналогом до розроблюваної системи є застосунок
рівненського вищого навчального закладу. Застосунок у фокусі має декілька переваг.
Основною перевагою є дизайн додатку. До розробки дизайну застосунку «Студент
ЧДТУ» не ставилися високі вимоги, тому маємо не ідеальний дизайн сторінок та
деяких компонентів. Другою перевагою рівненського додатку є кількість і об’єм
реалізованого функціоналу та інструментарію. Це пояснюється кількістю витрачених
людино-годин на розробку, проектування та удосконалення програми. Співставивши
це з обмеженими термінами на реалізацію застосунку черкаського університету,
можна побачити, наскільки ефективно проводилася розробка застосунку. Об’єм
проробленої роботи від початку і до сьогодні колосальний.
Отже, в ході роботи була спроектована, розроблена та випущена у публічний
доступ система мобільного застосунку для студентів ЧДТУ. Додаток містить більше
десяти функцій корисних для студента в рамках університету. Ним вже користуються
і є позитивні відгуки від користувачів. На стадії підтримки планується вдосконалення
застосунку та вже розпочато збір заявок і вимог на новий функціонал системи. Код
застосунку надано у додатках (Додаток Б).

62
ЧДТУ 232098.002 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Introdaction. Офіційний гайд по React Native [Електронний ресурс] //
Офіційний сайт React Native — Режим доступу до ресурсу:
https://reactnative.dev/docs/getting-started.
2 Xamarin [Електронний ресурс] // Офіційна сторінка Xamarin — Режим
доступу до ресурсу: https://dotnet.microsoft.com/en-us/apps/xamarin.
3 Створення додатку на Flutter: перші кроки [Електронний ресурс] /
Євгеній Єфрємов // Dou ua — 2019 — Режим доступу до ресурсу:
https://dou.ua/lenta/articles/flutter-first-steps.
4 Dart tutorial [Електронний ресурс] // Офіційний сайт Dart — Режим
доступу до ресурсу: https://dart.dev/tutorials.
5 Мобільний застосунок рівненського університету [Електронний ресурс]
// Новини Рівного — 2018 — Режим доступу до ресурсу:
https://rivne.media/news/rivnenskiy-universitet-zapustiv-vlasniy-mobilniy-dodatok.
6 What is a linter? [Електронний ресурс] / Amy Valters // testRigor — 2022 —
Режим доступу до ресурсу: https://testrigor.com/blog/what-is-a-linter.
7 What is the Agile methodology? [Електронний ресурс] // Atlassian —
Режим доступу до ресурсу: https://www.atlassian.com/agile.
8 UML diagrams [Електронний ресурс] // Smartdraw — Режим доступу до
ресурсу: https://www.smartdraw.com/uml-diagram.
9 Types of UML diagrams [Електронний ресурс] // Lucidchart — Режим
доступу до ресурсу: https://www.lucidchart.com/blog/types-of-UML-
diagrams#:~:text=What%20are%20UML%20diagrams%3F,implementation%20of%20co
mplex%20software%20systems.
10 Class diagram [Електронний ресурс] // Wikipedia — Режим доступу до
ресурсу: https://en.wikipedia.org/wiki/Class_diagram.
11 Діаграма пакетів [Електронний ресурс] // Wikiwand — Режим доступу до
ресурсу: https://www.wikiwand.com/uk/ Діаграма_пакетів.
12 Component diagram [Електронний ресурс] // Wikipedia — Режим доступу
до ресурсу: https://en.wikipedia.org/wiki/Component_diagram.
63
ЧДТУ 232098.002 ПЗ
13 Deployment diagram [Електронний ресурс] // Wikipedia — Режим доступу
до ресурсу: https://en.wikipedia.org/wiki/Deployment_diagram.
14 Sequence diagram [Електронний ресурс] // Wikipedia — Режим доступу до
ресурсу: https://en.wikipedia.org/wiki/Sequence_diagram.
15 Comunication diagram [Електронний ресурс] // Wikipedia — Режим
доступу до ресурсу: https://en.wikipedia.org/wiki/Communication_diagram.
16 Сторінка вибіркових дисциплін [Електронний ресурс] // ЧДТУ — Режим
доступу до ресурсу: https://ep.chdtu.edu.ua/vybirkovi-dysczypliny.
17 How do you gather requirements [Електронний ресурс] / Yulia Kosarenko //
why-change — 2022 — Режим доступу до ресурсу: https://ep.chdtu.edu.ua/vybirkovi-
dysczypliny.
18 Project requirements gathering: observations [Електронний ресурс] //
pmmajik — Режим доступу до ресурсу: https://www.pmmajik.com/project-requirement-
gathering-observations.
19 Project requirements gathering: surveys and questionnaires [Електронний
ресурс] // pmmajik — Режим доступу до ресурсу: https://www.pmmajik.com/project-
requirement-gathering-surveys-and-questionnaires.
20 Прототипування в процесі розробки ПЗ [Електронний ресурс] // studfiles
— Режим доступу до ресурсу: https://studfile.net/preview/4452595/page:13/
21 Build a form with validation [Електронний ресурс] // Flutter офіційний guide
по розробці — Режим доступу до ресурсу:
https://docs.flutter.dev/cookbook/forms/validation.
22 Add session support Flutter with Flutter session [Електронний ресурс] //
Flutter офіційний guide по розробці — Режим доступу до ресурсу:
https://medium.com/@jhourlad01/introducing-session-to-flutter-6b6354ec6ade.
23 Checkbox class [Електронний ресурс] // офіційна документація Flutter —
Режим доступу до ресурсу: https://api.flutter.dev/flutter/material/Checkbox-class.html.
24 What is a state manager [Електронний ресурс] // reatom — Режим доступу
до ресурсу: https://www.reatom.dev/general/what-is-state-manager.
64
ЧДТУ 232098.002 ПЗ
25 InheritedWidget class [Електронний ресурс] // Офіційна документація
Flutter — Режим доступу до ресурсу:
https://api.flutter.dev/flutter/widgets/InheritedWidget-class.html.
26 MaterialApp class [Електронний ресурс] // Офіційна документація Flutter
— Режим доступу до ресурсу: https://api.flutter.dev/flutter/material/MaterialApp-
class.html.
27 Material design [Електронний ресурс] // m3.material — Режим доступу до
ресурсу: https://m3.material.io.
28 What is a REST API [Електронний ресурс] / Lokesh Gupta // REST API
tutorial — 2022 — Режим доступу до ресурсу: https://restfulapi.net.
29 Аутентифікація і авторизація: що це і в чому відмінність [Електронний
ресурс] // qagroup — Режим доступу до ресурсу:
https://qagroup.com.ua/publications/autentyfikatciia-i-avtoryzatciia.
30 Документація по Flutter Bloc [Електронний ресурс] // pub.dev — Режим
доступу до ресурсу: https://pub.dev/packages/flutter_bloc.
31 Human Interface Guidelines [Електронний ресурс] // Developer Apple —
Режим доступу до ресурсу: https://developer.apple.com/design/human-interface-
guidelines.
32 Офіційна сторінка Ionic framework [Електронний ресурс] //
ionicframework — Режим доступу до ресурсу: https://ionicframework.com.
33 Офіційна сторінка Android Studio IDE [Електронний ресурс] // Android
Studio — Режим доступу до ресурсу: https://developer.android.com/studio.
34 Офіційна сторінка Intellij IDEA [Електронний ресурс] // jetbrains —
Режим доступу до ресурсу: https://www.jetbrains.com/idea.
35 Документація по Flutter Dio [Електронний ресурс] // pub.dev — Режим
доступу до ресурсу: https://pub.dev/packages/dio.
36 Flutter_test Library [Електронний ресурс] // Flutter — Режим доступу до
ресурсу: https://api.flutter.dev/flutter/flutter_test/flutter_test-library.html.
37 Офіційна сторінка сервісу Onesignal [Електронний ресурс] — Режим
доступу до ресурсу: https://onesignal.com.
65
ЧДТУ 232098.002 ПЗ
38 Google Play сторінка застосунку «Студент ЧДТУ» [Електронний ресурс]
// Google Play — Режим доступу до ресурсу:
https://play.google.com/store/apps/details?id=ua.edu.chdtu.deanoffice.student_mobile_cro
ss.
39 Notifications [Електронний ресурс] / Firebase — Режим доступу до
ресурсу: https://firebase.flutter.dev/docs/messaging/notifications.
40 Simple app state manager Flutter [Електронний ресурс] / офіційна
документація Flutter — Режим доступу до ресурсу: https://docs.flutter.dev/data-and-
backend/state-mgmt/simple.

66

ДОДАТОК А

ЗАТВЕРДЖЕНО:
Зав. кафедри ПЗАС
проф. Голуб С.В.
___________________________

МОБІЛЬНИЙ ЗАСТОСУНОК «СТУДЕНТ ЧДТУ»

Специфікація
ЧДТУ.232098-002 ПЗ
Листів 2

Розробник ________________ Архіпов М.О.

Керівник ________________ Заспа Г.О.

Н.Контроль ________________ Півень О.Б.

Черкаси 2023

ЧДТУ.232098-002 ПЗ 2

Специфікація
Позначення Найменування Примітка
482.ЧДТУ.232098-01 12-01 Лістинг програми
482.ЧДТУ.232098-01 34-01 Інструкція користувача
482.ЧДТУ.232098-01 90-01 Презентація

68

ДОДАТОК Б

МОБІЛЬНИЙ ЗАСТОСУНОК «СТУДЕНТ ЧДТУ»

Лістинг програми
482.ЧДТУ.232098-01 12-01
Листів 18

Розробник ________________ Архіпов М.О.

Черкаси 2023

482.ЧДТУ.232098-01 12-01 2

Текст коду мобільного застосунку «Студент ЧДТУ»
Весь код програми поділено на декілька модулів. Основні з модулів будуть
надані відповідно до ієрархії у проекті.

Main.dart

void main() {
late final appBloc;

runZonedGuarded(() async {
appBloc = AppBloc();
runApp(RootWidget(appBloc));
}, (e, stackTrace) {
final isHttpException = e is BlocUnhandledErrorException || e is DioError;
final isTypeImplementationException =
e.runtimeType.toString() == 'TypeErrorImpl' ||
e is TypeImplementationException;

if (isHttpException) {
late final error; // IDE marks 'e' as Object and shows Error

if (e is BlocUnhandledErrorException) {
error = e.error;
} else if (e is DioError) {
error = e.error;
}

if (error is Exception) {
appBloc.add(ExceptionEvent(error));
} else if (error.runtimeType.toString() == 'TypeErrorImpl') {
appBloc.add(ExceptionEvent(TypeImplementationException()));
} else {
appBloc.add(ExceptionEvent(Exception()));
print('--- Start of ${e.runtimeType}');
print(e);
print('--- End of ${e.runtimeType}');
}
70
482.ЧДТУ.232098-01 12-01 3

return;
} else if (isTypeImplementationException) {
appBloc.add(ExceptionEvent(TypeImplementationException()));

return;
}

final debugInfo =
'[${e.runtimeType}] ${e.toString()} Stacktrace: $stackTrace';
appBloc.add(ExceptionEvent(Exception(debugInfo)));

print(e);
print(e.runtimeType);
print(stackTrace);
});
}

class RootWidget extends StatefulWidget {
final AppBloc appBloc;

const RootWidget(this.appBloc);

@override
State<RootWidget> createState() => _RootWidgetState();
}

class _RootWidgetState extends State<RootWidget> {
bool progressIndicatorVisible = false;

@override
void initState() {
super.initState();
widget.appBloc.initOnesignal();
}

@override
Widget build(BuildContext context) => MaterialApp(
71
482.ЧДТУ.232098-01 12-01 4

locale: Locale('uk', 'UA'),
supportedLocales: [
Locale('en', ''),
Locale('uk', 'UA'),
],
localizationsDelegates: [
GlobalMaterialLocalizations.delegate,
GlobalWidgetsLocalizations.delegate,
GlobalCupertinoLocalizations.delegate,
],
debugShowCheckedModeBanner: false,
title: Strings.appName,
theme: ThemeData(
primarySwatch: Colors.blue,
scaffoldBackgroundColor: Colors.white,
),
home: BlocProvider(
create: (context) => widget.appBloc,
child: BlocConsumer<AppBloc, AppState>(
listenWhen: (_, state) =>
state is ExceptionState || state is ProgressIndicatorState,
listener: _listener,
buildWhen: (_, state) =>
state is LoggedInState ||
state is LoggedOutState ||
state is SplashScreenWidget ||
state is DegreeChangedState,
builder: (_, state) {
final isHomeScreen = state is LoggedInState ||
state is DegreeChangedState;

if (isHomeScreen) {
return HomeScreen();
}

if (state is LoggedOutState) {
return LoginScreen();
}
72
482.ЧДТУ.232098-01 12-01 5

if (state is SplashScreenState) {
widget.appBloc.add(InitEvent());
}

return SplashScreenWidget();
},
),
),
);

void _listener(context, state) {
if (state is ExceptionState) {
_handleException(context, state);
} else if (state is ProgressIndicatorState) {
_toggleProgressIndicator(context, showIndicator: state.visible);
}
}

Future _handleException(BuildContext context, ExceptionState state) async {
if (progressIndicatorVisible) {
_toggleProgressIndicator(context, showIndicator: false);
}

final errorObject = state.exception;
final exception = errorObject is DioError ? errorObject.error : errorObject;

if (exception is AppVersionException) {
_showVersionWarning(context);
widget.appBloc.add(LogOutEvent());
} else if (exception is ConnectionException) {
Utils.showSnackBar(context, Strings.connectionError);
} else if (exception is UnauthorizedException) {
Utils.showSnackBar(context, Strings.unauthorizedException);
widget.appBloc.add(LogOutEvent());
} else if (exception is ServerUnknownException) {
_showErrorDialog(context, Strings.serverUnknownException);
} else if (exception is TypeImplementationException) {
73
482.ЧДТУ.232098-01 12-01 6

_showErrorDialog(context, Strings.typeImplementationException);
} else {
_showErrorDialog(context, Strings.unknownError);
context.read<AppBloc>().add(LogOutEvent());
}
}

void _toggleProgressIndicator(
BuildContext context, {
required bool showIndicator,
}) {
if (showIndicator && !progressIndicatorVisible) {
progressIndicatorVisible = true;

showDialog(
barrierDismissible: false,
context: context,
builder: (context) => LoadingModalIndicator(),
).whenComplete(() => progressIndicatorVisible = false);
} else if (!showIndicator && progressIndicatorVisible) {
Navigator.of(context).pop();
}
}

void _showErrorDialog(context, message) {
showDialog(
context: context,
builder: (context) => ErrorDialog(message),
);
}

void _showVersionWarning(context) => showDialog(
context: context,
builder: (context) => AppVersionExceptionDialog(),
);
}

74
482.ЧДТУ.232098-01 12-01 7

Global_interceptor.dart

class GlobalInterceptor extends Interceptor {
final Map<String, dynamic> headers = {
'X-App-Version': appVersion,
};

@override
Future onRequest(
RequestOptions options,
RequestInterceptorHandler handler,
) async {
// Параметри запиту
final httpMethod = options.method;
final uri = options.uri;

// Вивід інформації для дебагу
print('Dio: $httpMethod $uri');

// Перевірка, чи існує кеш з такими параметрами запиту
final cache = Cache.get(Cache.genCacheId(options));
final shouldDisableCaching = options.extra['cachingDisabled'] ?? false;

// Якщо кеш є і кешування ввімкнено, беру відповідь з кешу
if (cache != null && !shouldDisableCaching) {
print('Dio: [cached] $uri');
handler.resolve(Response(requestOptions: options, data: cache));
return;
}

// Інакше додаю усі необхідні заголовки і здійснюю новий запит
final updatedOptions = await addHeaders(options);
super.onRequest(updatedOptions, handler);
}

@override
void onResponse(Response response, ResponseInterceptorHandler handler) {
// Параметри запиту
75
482.ЧДТУ.232098-01 12-01 8

final statusCode = response.statusCode;
final uri = response.requestOptions.uri;

// Вивід інформації для дебагу
print('Dio: [$statusCode] $uri');

// Кешую результат
Cache.save(Cache.genCacheId(response.requestOptions), response.data);
super.onResponse(response, handler);
}

@override
void onError(DioError error, ErrorInterceptorHandler handler) {
// Параметри запиту
final statusCode = error.response?.statusCode;
final uri = error.requestOptions.uri;

// Вивід інформації для дебагу
print('Dio: [$statusCode] $uri');

// Якщо не задано стутус код, виводжу усю можливу корисну інформацію
if (statusCode == null) {
print('Dio error[statusMessage]: ${error.response?.statusMessage}');
print('Dio error[error]: ${error.error}');
print('Dio error[message]: ${error.message}');
}

// Відповідно до статусу викидую вийняток
if (statusCode == null) throw ConnectionException();
if (statusCode == 401) throw AppVersionException();
if (statusCode == 403) throw UnauthorizedException();
throw ServerUnknownException(statusCode);
}

Future<RequestOptions> addHeaders(RequestOptions options) async {
// Отримую токен авторизації зі сховища
final token = await Token.getTokenFromStorage();
final bearerToken = token?.token ?? '';
76
482.ЧДТУ.232098-01 12-01 9

// Додаю авторизаційний заголовок
headers.addAll({'Authorization': 'Bearer $bearerToken'});

// Додаю заголовки до запиту і повертаю його
options.headers.addEntries(headers.entries);
return options;
}
}

Dio.dart

abstract class DioWrapper {
static const timeout = 30000;

static Dio? _dio;

static Dio getDio() => _dio = _dio ?? _createDio();

static Dio _createDio() {
// Конфігурація для Dio конструктора
final dioConfig = BaseOptions(
connectTimeout: timeout,
receiveTimeout: timeout,
baseUrl: apiUrl,
);
final dio = Dio(dioConfig);

// Додаю колбек на випадок зіпсованого сертифікату
HttpOverrides.global = BadCertificateCallbackOverrides();

// Повертаю сконфігурований Dio-обʼєкт, який проходить
// через глобальний інтерсептор
return _addInterceptors(dio);
}

// Метод навішування глобального інтерсептору
77
482.ЧДТУ.232098-01 12-01 10

static Dio _addInterceptors(Dio dio) =>
dio..interceptors.add(GlobalInterceptor());
}

// Клас для обробки невірних сертифікатів
class BadCertificateCallbackOverrides extends HttpOverrides {
@override
HttpClient createHttpClient(SecurityContext? context) =>
super.createHttpClient(context)
..badCertificateCallback =
((X509Certificate cert, String host, int port) => true);
}

App_block.dart

part 'app_event.dart';
part 'app_state.dart';

class AppBloc extends Bloc<AppEvent, AppState> {
final StudentRepository _studentRepository = StudentRepository();
static Student? _student;
static StudentDegree? _selectedDegree;
static AppBloc? _instance;

AppBloc() : super(SplashScreenState()) {
_instance = this;

on<InitEvent>((event, emit) async {
emit(ProgressIndicatorState(visible: true));
final token = await Token.getTokenFromStorage();

if (token == null) {
emit(LoggedOutState());
} else {
await _loadStudent(emit);
emit(LoggedInState());
}
78
482.ЧДТУ.232098-01 12-01 11

emit(ProgressIndicatorState(visible: false));
});

on<LogInEvent>((event, emit) async {
await _loadStudent(emit);
emit(LoggedInState());
});

on<LogOutEvent>((event, emit) {
Token.clear();
emit(LoggedOutState());
});

on<ExceptionEvent>((event, emit) {
emit(ExceptionState(event.exception));
});

on<ToggleProgressIndicatorEvent>((event, emit) {
emit(ProgressIndicatorState(visible: event.showIndicator));
});

on<ChangeStudentDegreeEvent>((event, emit) {
final degreeId = event.studentDegreeId;

_selectedDegree = _student?.getDegreeById(degreeId);
_studentRepository.setSelectedStudentDegreeId(degreeId);

emit(DegreeChangedState());
});
}

static AppBloc getInstance() {
if (_instance == null) {
throw Exception('getInstance(): Instance of AppBlock is null');
}

return _instance!;
79
482.ЧДТУ.232098-01 12-01 12

}

static StudentDegree getSelectedStudentDegree() {
if (_selectedDegree == null) {
throw Exception('getStudent(): Student object is null');
}

return _selectedDegree!;
}

static Student getStudent() {
if (_student == null) {
throw Exception('getStudent(): Student object is null');
}

return _student!;
}

Future initOnesignal() async {
final settingKey = SettingsKey.pushNotifications;
final pushState = await SettingsCubit.loadBooleanOption(settingKey);
final option = SettingOptions.getOption(settingKey);

OneSignalHelper.init(enablePush: pushState ?? option.boolValue ?? true);
}

void showProgressIndicator() {
add(ToggleProgressIndicatorEvent(showIndicator: true));
}

void hideProgressIndicator() {
add(ToggleProgressIndicatorEvent(showIndicator: false));
}

static void changeStudentDegree(int studentDegreeId) {
final event = ChangeStudentDegreeEvent(studentDegreeId: studentDegreeId);

_instance?.add(event);
80
482.ЧДТУ.232098-01 12-01 13

}

Future _loadStudent(Emitter emit) async {
try {
_student = await _studentRepository.getStudent();
await _loadStudentDegree();
} catch (errorObject) {
final exception = errorObject is DioError ? errorObject : Exception();
emit(ExceptionState(exception));
}
}

Future _loadStudentDegree() async {
final lastSelectedDegreeId =
await _studentRepository.getSelectedStudentDegreeId();

_selectedDegree = lastSelectedDegreeId != null
? _student?.getDegreeById(lastSelectedDegreeId)
: _student?.degree;
}
}

App_states.dart

part of 'app_bloc.dart';

@immutable
abstract class AppState {}

class SplashScreenState extends AppState {}

class LoggedInState extends AppState {}

class LoggedOutState extends AppState {}

class ExceptionState extends AppState {
final Exception exception;
81
482.ЧДТУ.232098-01 12-01 14

ExceptionState(this.exception);
}

class ProgressIndicatorState extends AppState {
final bool visible;

ProgressIndicatorState({required this.visible});
}

class DegreeChangedState extends AppState {}

App_event.dart

part of 'app_bloc.dart';

@immutable
abstract class AppEvent {}

class InitEvent extends AppEvent {}

class ToggleProgressIndicatorEvent extends AppEvent {
final bool showIndicator;

ToggleProgressIndicatorEvent({required this.showIndicator});
}

class LogInEvent extends AppEvent {}

class LogOutEvent extends AppEvent {}

class ExceptionEvent extends AppEvent {
final Exception exception;

ExceptionEvent(this.exception);
}

82
482.ЧДТУ.232098-01 12-01 15

class ChangeStudentDegreeEvent extends AppEvent {
final int studentDegreeId;

ChangeStudentDegreeEvent({required this.studentDegreeId});
}

Onesignal.dart

abstract class OneSignalHelper {
static bool _initiated = false;

static Future init({bool enablePush = false}) async {
if (_initiated) return;

_initiated = true;

OneSignal.shared.setLogLevel(OSLogLevel.none, OSLogLevel.none);
await OneSignal.shared.setAppId(onesignalAppId);

// iOS-only method to open launch URLs in Safari when set to false
OneSignal.shared.setLaunchURLsInApp(false);
OneSignal.shared.disablePush(!enablePush);

SettingsCubit.subscribeOnUpdates(
(settingOption) {
if (settingOption.key.isPushNotifications) {
final option = SettingOptions.getOption(settingOption.key);
final isEnable = settingOption.boolValue ?? option.boolValue ?? true;

OneSignal.shared.disablePush(!isEnable);
}
},
);
}
}

83
482.ЧДТУ.232098-01 12-01 16

Pubspec.yaml

name: deanoffice_mobile_cross
description: A new Flutter project.

# The following line prevents the package from being accidentally published to
# pub.dev using `pub publish`. This is preferred for private packages.
publish_to: 'none' # Remove this line if you wish to publish to pub.dev

# The following defines the version and build number for your application.
# A version number is three numbers separated by dots, like 1.2.43
# followed by an optional build number separated by a +.
# Both the version and the builder number may be overridden in flutter
# build by specifying --build-name and --build-number, respectively.
# In Android, build-name is used as versionName while build-number used as versionCode.
# Read more about Android versioning at https://developer.android.com/studio/publish/versioning
# In iOS, build-name is used as CFBundleShortVersionString while build-number used as CFBundleVersion.
# Read more about iOS versioning at
#
https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/Core
FoundationKeys.html
version: 1.1.0+7

environment:
sdk: ">=2.17.0 <3.0.0"

dependencies:
flutter:
sdk: flutter
flutter_localizations:
sdk: flutter
select_form_field: ^2.2.0
google_fonts: ^2.1.0
flutter_bloc: ^7.0.0
cupertino_icons: ^1.0.2
provider: ^6.0.2
json_annotation: ^4.4.0
84
482.ЧДТУ.232098-01 12-01 17

share_plus: ^4.0.6
intl: ^0.17.0
flutter_markdown: ^0.6.9
equatable: ^2.0.3
dio: ^4.0.6
auto_size_text: ^3.0.0
flutter_secure_storage: ^5.0.2
shared_preferences: ^2.0.13
onesignal_flutter: ^3.3.1
url_launcher: ^6.1.5

dev_dependencies:
flutter_test:
sdk: flutter
build_runner: ^2.1.5
json_serializable: ^6.0.1

# For information on the generic Dart part of this file, see the
# following page: https://dart.dev/tools/pub/pubspec

# The following section is specific to Flutter.
flutter:

# The following line ensures that the Material Icons font is
# included with your application, so that you can use the icons in
# the material Icons class.
uses-material-design: true

# To add assets to your application, add an assets section, like this:
assets:
- assets/images/chdtu_logo.jpg
- assets/images/female-user-account.png
- assets/images/male-user-account.png

# An image asset can refer to one or more resolution-specific "variants", see
# https://flutter.dev/assets-and-images/#resolution-aware.

# For details regarding adding assets from package dependencies, see
85
482.ЧДТУ.232098-01 12-01 18

# https://flutter.dev/assets-and-images/#from-packages

# To add custom assets.fonts to your application, add a assets.fonts section here,
# in this "flutter" section. Each entry in this list should have a
# "family" key with the font family name, and a "assets.fonts" key with a
# list giving the asset and other descriptors for the font. For
# example:
# assets.fonts:
# - family: Schyler
# assets.fonts:
# - asset: assets.fonts/Schyler-Regular.ttf
# - asset: assets.fonts/Schyler-Italic.ttf
# style: italic
# - family: Trajan Pro
# assets.fonts:
# - asset: assets.fonts/TrajanPro.ttf
# - asset: assets.fonts/TrajanPro_Bold.ttf
# weight: 700
#
# For details regarding assets.fonts from package dependencies,
# see https://flutter.dev/custom-fonts/#from-packages

86

ДОДАТОК В

МОБІЛЬНИЙ ЗАСТОСУНОК «СТУДЕНТ ЧДТУ»

Інструкція користувача
482.ЧДТУ.232098-01 34-01
Листів 3

Розробник ________________ Архіпов М.О.

Черкаси 2023

482.ЧДТУ.232098-01 34-01 2

Інструкція користувача
Вимоги до пристрою користувача: Android вище версії 6.2. Пристрій повинен
бути справний та мати екран більший за 370 пікселів в ширину.
Додаток можна завантажити з Google Play. Після завантаження при першому
запуску необхідно пройти авторизацію (рис. Б.1). Логіном для входу слугує
внутрішня пошта студента. Пароль генерується системою і видається студенту при
вступі в навчальний заклад.
Рис. Б.1 – Форма авторизації

Після входу, користувач опиняється на головній сторінці, де є нижнє меню.
Застосунок містить декілька меню навігації. Нижня полоса меню на головних
сторінках містить наступні сторінки: новини – вона ж головна, заяви, розклад,
профіль та інше (рис. Б.2).
Рис. Б.2 – Полоса нижнього (головного) меню застосунку

На сторінці «інше» користувач може перейти до додаткового функціоналу.
Серед якого: вибіркові дисципліни, опитування, навчальний план та кнопка виходу з
застосунку (рис. Б.3).
88
482.ЧДТУ.232098-01 34-01 3

Рис. Б.3 – Полоса нижнього (головного) меню застосунку

У профілі (рис. Б.4) користувач може побачити інформацію про себе та три
додаткові кнопки: сервісна підтримка, налаштування та продубльовано кнопку
виходу.
Рис. Б.4 – Сторінка профілю

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

89

ДОДАТОК Г

МОБІЛЬНИЙ ЗАСТОСУНОК «СТУДЕНТ ЧДТУ»

Презентація
482.ЧДТУ.232098-01 90-01
Листів 6

Розробник ________________ Архіпов М.О.

Черкаси 2023

482.ЧДТУ.232098-01 90-01 2

Презентація
Рис. Г.1 – Слайд 1
Рис. Г.2 – Слайд 2
Рис. Г.3 – Слайд 3

91
482.ЧДТУ.232098-01 90-01 3

Рис. Г.3 – Слайд 3
Рис. Г.4 – Слайд 5
Рис. Г.6 – Слайд 6
92
482.ЧДТУ.232098-01 90-01 4

Рис. Г.7 – Слайд 7
Рис. Г.8 – Слайд 8
Рис. Г.9 – Слайд 9
93
482.ЧДТУ.232098-01 90-01 5

Рис. Г.10 – Слайд 10
Рис. Г.11 – Слайд 11

Рис. Г.12 – Слайд 12
94
482.ЧДТУ.232098-01 90-01 6

Рис. Г.13 – Слайд 13
Рис. Г.14 – Слайд 14

95

Репозиторій ЧДТУ